LLVM の RISC-V での 25% の性能劣化の原因追跡

前回の投稿と同様に、本稿では RISC-V ターゲットにおけるベンチマークに関する私の分析結果について記述します。前回とは異なり、この特定のベンチマークにおいて GCC とのパフォーマンスのギャップを消滅させるパッチに合意することができました！

まとめ (TLDR) 最近の LLVM コミットにより、

isKnownExactCastIntToFP

fpext(sitofp x to float)

uitofp x to double

fpext

visitFPTrunc

fdiv.d

fdiv.s

getMinimumFPType

分析

Igalia のサイトで、RISC-V ターゲットにおける LLVM と GCC パフォーマンスの比較を調査していた際、この特定のベンチマークに注意を向けていました。

以下の画像（※実際には挿入不可ですが）に示すように、Sifive P550 CPU 上で特定の本番タスクにおいて、LLVM は GCC よりも約 ~8% 多くのサイクルを必要としていました。

関連する基本ブロックアセンブリの断片を含めています。実質的にすべてのサイクルは以下のアセンブリによって消費されていました。

• LLVM: [アセンブリ断片]
• GCC: [アセンブリ断片]

この 2 つのアセンブリを比較しても、なぜ GCC が優れているのかは直ちに明らかではありませんでした。むしろ非常に似ており、LLVM はここでのブランチ論理さえ最適化できているように見えました。私が確認した大きな違いは、LLVM が倍精度浮動小数点（f64）の除算である

fdiv.d

これは有望な兆候だったので、より詳細な状況を把握するために

llvm-mca

llvm-mca

llvm-mca

fdiv.d

fdiv.d

情報

llvm-mca

$LLVM_BUILD_DIR/bin/llvm-mca -mtriple=riscv64 -mcpu=sifive-p550 pi.s

本来

fdiv.d

fdiv.s

fdiv.d

これを事実上の回帰であることを確認するために、同じ CPU およびベンチマークに対する以前の LLVM ビルドと比較を行いました。 https://cc-perf.igalia.com/db_default/v4/nts/profile/260/406/4

以下は、以前ビルドされた LLVM が生成したアセンブリです。 以前のビルドでは

fdiv.d

fdiv.s

乱次実装 (Out-of-Order Execution)

上記のアセンブリと新しい LLVM ビルドのアセンブリの順序が異なる理由を気にされている場合は、ターゲット CPU の Sifive P550 は乱次実行 CPU（out of order CPU）であるためです。前回の投稿で言及された Banana Pi の CPU とは異なり、インオーダー CPU であり、このターゲットはより高いスループットを生み出せる順序で命令を実行することができます。

なぜ

fdiv.d

fdiv.d

fcvt.s.d

ここでは何が起きているのか？

現時点ではなぜこれが起きたのかは分かりませんが、正しい方向への一歩としては、どこで起こっているかを特定することになるでしょう。もしかすると RISC-V バックエンドの変更かもしれませんか。以下のコマンドが RISC-V に関連するコミットを表示してくれます。

git log --after="2026-04-01 00:11" --before="2026-04-04 00:10" | grep -E "RISC"

• [RISCV] P 拡張に対して add(vec, splat(scalar)) を PADD_*S に選択 (#190303)
• [RISCV] vsetvli のバリアント化を許可する LI に coalesceVSETVLIs を移動させることを許可 (#190287)
• [RISC-V][TTI] vector.extract.last.active のコストを更新し、m8 超過を防ぐ (#188160)
• [RISCV] RISCSIInsertVSETVLI::transferBefore 内で EnsureWholeVectorRegisterMoveValidVTYPE をチェック (#190022)
• [RISCV] vp_ctlz, vp_cttz, vp_ctpop のコード生成を削除 (#189904)
  • RISC-V から自明な VP 内在関数を削除する一環として行われました。
• [RISCV] RISCVLoadStoreOptimizer でペアになっていない命令を後ろに移動 (#189912)

  • RISCVLoadStoreOptimizer

    は他の命令に隣接する命令を移動させます。
• [RISCV] 圧縮ターゲットに対してスタックマップシャドウの NOP サイズを修正 (#189774)
• [RISCV] convertSameMaskVMergeToVMv の VL 制約を緩和 (#189797)
• [RISCV] RISCVOptWInstrs に SATI_RV64/USATI_RV64 を追加 (#190030)
  • RISCVISD::SATI エンコーディングはタイプ幅から 1 を減らします。
• [RISCV][MCA] Sifive-p670 テストをファイル入力を使用するように更新 (#189785)
• [RISCV] vp_minnum, vp_maxnum のコード生成を削除 (#189899)
  • RISC-V から自明な VP 内在関数を削除する一環として行われました。
• [RISCV] ComputeKnownBitsForTargetNode/ComputeNumSignBitsForTargetNode に RISCVISD::USATI/SATI を追加 (#189702)
• [RISCV] VSETVLIInfo::hasSEWLMULRatioOnly() へのアサーションを追加。NFC (#189799)
• [RISCV] combine-is_fpclass.ll - ISD::IS_FPCLASS ノードの定数畳み込み失敗を示す初期テストを追加 (#189940)
• [RISCV] VP 浮動小数点丸め内在関数のコード生成を削除 (#189896)
  • RISC-V から自明な VP 内在関数を削除する一環として行われました。
• [RISCV] vp_lrint, vp_llrint のコード生成を削除 (#189714)
  • RISC-V から自明な VP 内在関数を削除する一環として行われました。
• [RISCV] SATI および USATI のコード生成サポートを追加 (#189532)

これらのコミットのどれもがすぐに目立ちませんでしたので、一旦保留しました。ミドルエンドの調査に戻り、ローカルの LLVM バージョン（数日前のものである）で

opt

私が何をしているのか混乱されている場合を想定して、上記の図がこれをより明確に示しているはずです。もしミドルエンドが double を float へ狭めるのに責任があるなら、IR に対してどのような最適化が行われ、それが生じたのかを理解しようとしています。

代わりに、特定のパスで print-before および print-after を使用することもできます。これで IR がどのように変更されているかをパースすることが可能です。

これは最適化パイプラインの最初に生成された IR の関連する断片です。

%conv  = sitofp i64 %5 to float        ; int -> float
%conv2 = fpext float %conv to double   ; float -> double 
%div3  = fdiv double %conv2, 7.438300e+04  ; fdiv.d 
%conv4 = fptrunc double %div3 to float ; double -> float

これは、パイプラインの終了時点では以下のようになります。

%conv  = uitofp nneg i64 %0 to float   ; int -> float 
%conv4 = fdiv float %conv, 7.438300e+04 ; fdiv.s 

これらを見てわかるように、ミドルエンドの終わりまでには double が float へと狭められていたことがわかります。これらの断片から、初期の double 値を float へと狭めるのはこのミドルエンドが責任を負っていることは明瞭であると確信します。

なぜ、これらの一見して冗長なキャスト操作が最初に生成されたのか混乱されている場合を想定して、ソースコードに一瞥するだけで理解が深まります。

ソース

int main(int argc, char *argv[]) {
  float ztot, yran, ymult, ymod, x, y, z, pi, prod;
  long int low, ixran, itot, j, iprod;

  ...

  for(j=1; j<=itot; j++) {
    iprod = 27611 * ixran;
    ixran = iprod - 74383*(long int)(iprod/74383);
    x = (float)ixran / 74383.0;

    ...

  }
    
  ...

}

この特定の行では、ソースコードにおいて

74383.0

x = (float)ixran / 74383.0;

fpext

fptrunc

fdiv.d

x = (float)ixran / 74383.0f;

以下の表は LLVM IR から C ソースへのマッピングを示し、指定された IR が何を行うかについての注記を簡潔に示しています。

%mul = mul nuw nsw i64 %ixran.053, 27611

iprod = 27611 * ixran

%0 = urem i64 %mul, 74383

ixran = iprod - 74383*(long int)(iprod/74383)

%conv2 = uitofp nneg i64 %0 to double

(float)ixran

74383.0

%div3 = fdiv double %conv2, 7.438300e+04

/ 74383.0

74383.0

%conv4 = fptrunc double %div3 to float

x = (float)...

(float)

当時のものであった LLVM ビルドでは、以下の IR が生成されていました。

%mul = mul nuw nsw i64 %ixran.053, 27611
%0 = urem i64 %mul, 74383
%conv2 = uitofp nneg i64 %0 to double
%div3 = fdiv double %conv2, 7.438300e+04
%conv4 = fptrunc double %div3 to float

div3

%conv2

%conv2

%0

%0

llvm-mca

fdiv.d

1      33    32.00                       fdiv.d   ft1, ft1, fa3

これは

fdiv.d

fdiv.s

上記の過去数日のコミットリストから、以下のものだけが直ちに目立ちました。 [InstCombine] ComputeNumSignBits in isKnownExactCastIntToFP を使用 (#190235)

符号付き整数から FP への変換において、

ComputeNumSignBits

ashr(shl x, a), b

InstCombine は LLVM ミドルエンドの最適化パスであり、隣接または関連する命令を単一のより効率的な操作へと結合します。その任務は幅広いので、InstCombine の最適化例は多岐にわたります。例えば、InstCombine は

x = x * 2

x = x << 1;

最新ビルドではもはやその整数を float へ変換できないため、この commit メッセージで言及されている int-to-FP キャスト (

sitofp/uitofp

fdiv.d

また、このパッチ自体が改善点であることも付け加えておきます。InstCombiner パスにはより多くの情報がありますが、場合によっては改善点が予期せぬ場所での回帰を引き起こす可能性があります。私は、私のような人々が貢献する機会を提供することを提案します 😅

なぜこれが起きたのか？

このコミットの差分を見ると、パッチの著者が関数

isKnownExactCastIntToFP

static bool isKnownExactCastIntToFP(CastInst &I, InstCombinerImpl &IC) {
  
  ...

  // For sitofp, the sign maps to the FP sign bit, so only magnitude bits
  // (BitWidth - NumSignBits) consume mantissa.
  if (IsSigned) {
    SigBits =
        (int)SrcTy->getScalarSizeInBits() - IC.ComputeNumSignBits(Src, &I);
    if (SigBits <= DestNumSigBits)
      return true;
  }

  return false;
}

この変更の詳細な理解は必要ありませんが、推測すると

isKnownExactCastIntToFP

true

isKnownExactCastIntToFP

以下の関数が

isKnownExactCastIntToFP

fpext

itofp i64 x to float

fpext float x to double

itofp i64 x to double

Instruction *InstCombinerImpl::visitFPExt(CastInst &FPExt) {
  // If the source operand is a cast from integer to FP and known exact, then
  // cast the integer operand directly to the destination type.
  Type *Ty = FPExt.getType();
  Value *Src = FPExt.getOperand(0);
  if (isa<SIToFPInst>(Src) || isa<UIToFPInst>(Src)) {
    auto *FPCast = cast<CastInst>(Src);
    if (isKnownExactCastIntToFP(*FPCast))
      return CastInst::Create(FPCast->getOpcode(), FPCast->getOperand(0), Ty);
  }

  return commonCastTransforms(FPExt);
}

そしてこれはそれを組み立てます。 パイプラインの最初に生成された LLVM IR を参照します。

%conv  = sitofp i64 %5 to float        ; int -> float
%conv2 = fpext float %conv to double   ; float -> double 
%div3  = fdiv double %conv2, 7.438300e+04  ; fdiv.d 
%conv4 = fptrunc double %div3 to float ; double -> float

そして、パイプラインの最後に生成された LLVM IR です。

%conv2 = uitofp nneg i64 %0 to double
%div3 = fdiv double %conv2, 7.438300e+04
%conv4 = fptrunc double %div3 to float

そのパッチ後の InstCombiner パスは、

sitofp i64

fpext float

uitofp nneg i64 %0 to double

visitFPTrunc

// 我々は fptrunc(OpI (fpextend x), (fpextend y)) を持つ場合、 // トリンク/拡張操作のうち一つ以上の操作なしに数値的結果を変更しないようにすることができれば、 // この式を簡略化することを望むべきである。 // // オペランドの幅が相互に作用して、何を実行し、何を安全に行えないかを制限する具体的な方法は、 // 操作ごとに異なり、以下の変なケースステートメントで説明されています。

最適化された LLVM IR はもはやその

fpext

visitFPTrunc

ソリューションの実装 (Landing a solution)

したがって、私たちは問題を診断しました - 最近の InstCombine パッチは論理を改善しましたが、それはパスが別の最適化を実行する能力を失う原因となりました。今後必要とされるのは、

fptrunc

uitofp/sitofp

最初に私は GitHub でイシューを立ち上げました。これは妥当な問題であると自信を持っていましたが、これが修正に値するのかを確認したかったのです。私以上に先に言及したパッチの著者である @SavchenkoValeriy には感謝しております。彼は私にこの問題を解決するためのガイダンスを提供し、私の PR に対してレビューを提供してくださったからです。私の最初のソリューションはかなり複雑なものになっていたでしょうが、彼は私にはるかにシンプルなアプローチを提供してくれました。

• GitHub Issue: https://github.com/llvm/llvm-project/issues/190503
• PR: https://github.com/llvm/llvm-project/pull/190550

レビュー者によって指摘された通り、現在の

isKnownExactCastIntToFP

CastInst

  %0 = urem i64 %mul, 74383
  %conv2 = uitofp nneg i64 %0 to double
  %div3 = fdiv double %conv2, 7.438300e+04
  %conv4 = fptrunc double %conv2 to float

以下は

visitFPTrunc

fdiv.d/fdiv.s

fptrunc

FPT.getOperand(0)

%conv2

uitofp

getMinimumFPType

Instruction *InstCombinerImpl::visitFPTrunc(FPTruncInst &FPT) {
  if (Instruction *I = commonCastTransforms(FPT))
    return I;
  
  ...

  Type *Ty = FPT.getType();
  auto *BO = dyn_cast<BinaryOperator>(FPT.getOperand(0));
  if (BO && BO->hasOneUse()) {
    Type *LHSMinType = getMinimumFPType(BO->getOperand(0), PreferBFloat);
    Type *RHSMinType = getMinimumFPType(BO->getOperand(1), PreferBFloat);

    switch (BO->getOpcode()) {
      default: break;
      case Instruction::FAdd:
      case Instruction::FSub:
      ...
  ...

私の初期のアイデアの一つは、

isKnownExactCastIntToFP

nullptr

isKnownExactCastIntToFP

canBeCastedExactlyIntToFP

isKnownExactCastIntToFP

以下が最終的な git diff です。私たちは

isKnownExactCastIntToFP

canBeCastedExactlyIntToFP

isKnownExactCastIntToFP

getMinimumFPType

canBeCastedExactlyIntToFP

--- a/llvm/include/llvm/Transforms/InstCombine/InstCombiner.h
+++ b/llvm/include/llvm/Transforms/InstCombine/InstCombiner.h
@@ -481,6 +481,8 @@ public:
   /// Return true if the cast from integer to FP can be proven to be exact
   /// for all possible inputs (the conversion does not lose any precision).
   bool isKnownExactCastIntToFP(CastInst &I) const;
+  bool canBeCastedExactlyIntToFP(Value *V, Type *FPTy, bool IsSigned,
+                                 const Instruction *CxtI = nullptr) const;

   OverflowResult computeOverflowForUnsignedMul(const Value *LHS,
                                                const Value *RHS,
--- a/llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp
+++ b/llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp
@@ -2039,10 +2039,17 @@ static Type *shrinkFPConstantVector(Value *V, bool PreferBFloat) {
 }

 /// Find the minimum FP type we can safely truncate to.
-static Type *getMinimumFPType(Value *V, bool PreferBFloat) {
+static Type *getMinimumFPType(Value *V, Type *PreferredTy, InstCombiner &IC) {
   if (auto *FPExt = dyn_cast<FPExtInst>(V))
     return FPExt->getOperand(0)->getType();

+  Value *Src;
+  if (match(V, m_IToFP(m_Value(Src))) &&
+      IC.canBeCastedExactlyIntToFP(Src, PreferredTy, isa<SIToFPInst>(V),
+                                   cast<Instruction>(V)))
+    return PreferredTy;
+

+  bool PreferBFloat = PreferredTy->getScalarType()->isBFloatTy();

見てわかる通り、私たちは今や

fptrunc

canBeCastedExactlyIntToFP

BO->getOperand(0)

fptruc

%0 = urem i64 %mul, 74383
%conv2 = uitofp nneg i64 %0 to double
%div3 = fdiv double %conv2, 7.438300e+04
%conv4 = fptrunc double %div3 to float

fptrunc

%div3

BO->getOperand(0)

%conv2

m_IToFP(m_Value(Src))

BO->getOperand(0)

%0

%div3

%conv2

7.438300e+04

%0

結果

これは機能しましたか？以下のコマンドを実行することで、私のパッチ後の LLVM IR を確認できます。

$LLVM_BUILD_DIR/bin/clang -O3 \
  --target=riscv64-unknown-linux-gnu \
  -march=rv64gc_zba_zbb \
  --sysroot=/usr/riscv64-linux-gnu \
  -S -emit-llvm pi.c -o pi_fixed.ll

そして、これは関連する LLVM IR です。

%mul = mul nuw nsw i64 %ixran.053, 27611
%0 = urem i64 %mul, 74383
%1 = uitofp nneg i64 %0 to float
%conv4 = fdiv float %1, 7.438300e+04

機能しました！🥹

fptrunc

uitofp