Rust: LLVMがnoaliasアノテーションを誤ってコンパイルしなくなったら、デフォルトでnoaliasアノテーションを再度有効にします

私はまだ根本的な問題を解明するために取り組んでいます。 興味深いチケットはhttps://github.com/rust-lang/rust/issues/54462です。

@nagisaの最小限の複製を使用する：

fn linidx(row: usize, col: usize) -> usize {
    row * 1 + col * 3
}

fn swappy() -> [f32; 12] {
    let mut mat = [1.0f32, 5.0, 9.0, 2.0, 6.0, 10.0, 3.0, 7.0, 11.0, 4.0, 8.0, 12.0];

    for i in 0..2 {
        for j in i+1..3 {
            if mat[linidx(j, 3)] > mat[linidx(i, 3)] {
                    for k in 0..4 {
                            let (x, rest) = mat.split_at_mut(linidx(i, k) + 1);
                            let a = x.last_mut().unwrap();
                            let b = rest.get_mut(linidx(j, k) - linidx(i, k) - 1).unwrap();
                            ::std::mem::swap(a, b);
                    }
            }
        }
    }

    mat
}

fn main() {
    let mat = swappy();
    assert_eq!([9.0, 5.0, 1.0, 10.0, 6.0, 2.0, 11.0, 7.0, 3.0, 12.0, 8.0, 4.0], mat);
}

LLVMの最適化パスを二等分して、エラーの原因となっているパスを見つけることができました。

このコマンドを実行すると、実行可能になります（ bug.rsを、複製を保存したファイルの名前に置き換えます）。

rustc -Z no-parallel-llvm -C codegen-units=1 -O -Z mutable-noalias=yes -C llvm-args=-opt-bisect-limit=2260 bug.rs

このコマンドを実行している間、実行可能ファイルが壊れます（ `assert_eq``は失敗します）：

rustc -Z no-parallel-llvm -C codegen-units=1 -O -Z mutable-noalias=yes -C llvm-args=-opt-bisect-limit=2261 bug.rs

LLVMバイセクト出力

このファイルの場合、最適化2261はGlobal Value Numbering on function (_ZN3bug6swappy17hdcc51d0e284ea38bE)対応します

LLVMリビジョンを二等分する（llvmlab二等分線を使用）と、r305936-r305938、おそらくr305938に絞り込まれます。

[BasicAA]フォールバックにPartialAliasの代わりにMayAliasを使用します。

これは2017年6月からのかなり古い変更であることに注意してください。

編集：コミットの説明を見ると、バグはそれ以前に存在していた可能性がありますが、BasicAAによってマスクされ、後のエイリアスパスが実行されないようになっています。これがコミットの修正です。 この場合、コンパイラが同じベースアドレスを持っていることは知っているが、オフセットは知らない、 getelementptr命令のペア間のエイリアシングをチェックする必要があります。

Edit2：また、LLVMオプションとして-enable-scoped-noalias=falseを渡すと、誤コンパイルを防ぐことができます。 （これにより、noaliasの処理が完全に無効になるため、これは驚くべきことではありませんが、念のために…）

GVN以前のIRを見ると、LLVMエイリアシングアノテーションがどのように機能するかについての私の理解が正しいかどうかによっては、ここでの根本的な原因がループ展開にある可能性があるように感じます。

次のようなコードを考えてみましょう

int *a, *b;
for (int i = 0; i < 4; i++) {
    a[i & 1] = b[i & 1];
}

ここで、 a[i & 1]とb[i & 1]は単一の反復内でエイリアスしませんが、 aとbは一般にエイリアスする可能性があります。

LLVM IRでは、これは次のようになります。

define void @test(i32* %addr1, i32* %addr2) {
start:
    br label %body

body:
    %i = phi i32 [ 0, %start ], [ %i2, %body ]
    %j = and i32 %i, 1
    %addr1i = getelementptr inbounds i32, i32* %addr1, i32 %j
    %addr2i = getelementptr inbounds i32, i32* %addr2, i32 %j

    %x = load i32, i32* %addr1i, !alias.scope !2
    store i32 %x, i32* %addr2i, !noalias !2

    %i2 = add i32 %i, 1
    %cmp = icmp slt i32 %i2, 4
    br i1 %cmp, label %body, label %end

end:
    ret void
}

!0 = !{!0}
!1 = !{!1, !0}
!2 = !{!1}

これを-loop-unrollすると、次のようになります。

define void @test(i32* %addr1, i32* %addr2) {
start:
  br label %body

body:                                             ; preds = %start
  %x = load i32, i32* %addr1, !alias.scope !0
  store i32 %x, i32* %addr2, !noalias !0
  %addr1i.1 = getelementptr inbounds i32, i32* %addr1, i32 1
  %addr2i.1 = getelementptr inbounds i32, i32* %addr2, i32 1
  %x.1 = load i32, i32* %addr1i.1, !alias.scope !0
  store i32 %x.1, i32* %addr2i.1, !noalias !0
  %x.2 = load i32, i32* %addr1, !alias.scope !0
  store i32 %x.2, i32* %addr2, !noalias !0
  %addr1i.3 = getelementptr inbounds i32, i32* %addr1, i32 1
  %addr2i.3 = getelementptr inbounds i32, i32* %addr2, i32 1
  %x.3 = load i32, i32* %addr1i.3, !alias.scope !0
  store i32 %x.3, i32* %addr2i.3, !noalias !0
  ret void
}

!0 = !{!1}
!1 = distinct !{!1, !2}
!2 = distinct !{!2}

ループの4つのコピーすべてが、同じエイリアシングドメインでエイリアシングメタデータを使用する方法に注意してください。 1回の反復でノエイリアスになるのではなく、関数全体でノエイリアスになります。

最後に、 -scoped-noalias -gvnは次のようになります。

define void @test(i32* %addr1, i32* %addr2) {
start:
  %x = load i32, i32* %addr1, !alias.scope !0
  store i32 %x, i32* %addr2, !noalias !0
  %addr1i.1 = getelementptr inbounds i32, i32* %addr1, i32 1
  %addr2i.1 = getelementptr inbounds i32, i32* %addr2, i32 1
  %x.1 = load i32, i32* %addr1i.1, !alias.scope !0
  store i32 %x.1, i32* %addr2i.1, !noalias !0
  store i32 %x, i32* %addr2, !noalias !0
  store i32 %x.1, i32* %addr2i.1, !noalias !0
  ret void
}

!0 = !{!1}
!1 = distinct !{!1, !2}
!2 = distinct !{!2}

また、 a = b + 1場合、これは誤った結果になります。

次のコードを使用して、Cからこの問題を再現することができます。

#include "stdio.h"

void copy(int * restrict to, int * restrict from) {
    *to = *from;
}

void test(int *a, int *b) {
    for (int i = 0; i < 4; i++) {
        copy(&b[i & 1], &a[i & 1]);
    }
}

int main() {
    int ary[] = {0, 1, 2};
    test(&ary[1], &ary[0]);
    printf("%d %d %d\n", ary[0], ary[1], ary[2]);
    return 1;
}

クラン6.0ではこれが印刷さ2 2 2で-O0と1 2 2で-O3 。 このコードがCのrestrictセマンティクスの下で合法かどうかはわかりませんが、LLVMのより厳密なnoaliasセマンティクスの下では合法であるはずです。

私はそれを単純なCテストケースに減らしました（-O3と-O0でコンパイルし、出力を比較します）：

#include <stdlib.h>
#include <stdio.h>
#include <assert.h>

__attribute__((always_inline))
static inline void copy(int *restrict a, int *restrict b) {
    assert(a != b);
    *b = *a;
    *a = 7;
}

__attribute__((noinline))
void floppy(int mat[static 2], size_t idxs[static 3]) {
    for (int i = 0; i < 3; i++) {
        copy(&mat[i%2], &mat[idxs[i]]);
    }
}

int main() {
    int mat[3] = {10, 20};
    size_t idxs[3] = {1, 0, 1};
    floppy(mat, idxs);
    printf("%d %d\n", mat[0], mat[1]);
}

restrictを削除すると、Cはnoaliasに相当し、動作は正しいことに注意してください。 それでも、 assert(a != b)合格し、 restrict呼び出すためにUBが発生しないことを証明します。

何が起こっているのですか：

1. copy（）がインライン化され、次のようになります。

for (int i = 0; i < 3; i++) {
    mat[idxs[i]] = mat[i%2]; mat[i%2] = 7;
}

1. LLVMはループを展開します：

mat[idxs[0]] = mat[0]; mat[0] = 7; /* from copy(&mat[0%2], &mat[idxs[0]]) */
mat[idxs[1]] = mat[1]; mat[1] = 7; /* from copy(&mat[1%2], &mat[idxs[1]]) */
mat[idxs[2]] = mat[0]; mat[0] = 7; /* from copy(&mat[2%2], &mat[idxs[2]]) */

1. LLVMは、 mat[0]はmat[idxs[1]]またはmat[1]でエイリアスできないと考えています。エルゴは、 mat[0] = 7;とmat[idxs[2]] = mat[0];間で変更できません。エルゴmat[idxs[2]] = 7;に最適化するためのグローバル値の番号付け。

ただし、 idxs[1] == 0であるため、 mat[0]はmat[idxs[1]]とエイリアスします。 また、 &mat[idxs[1]]がcopyに渡される2回目の反復では、他の引数は&mat[1]であるため、そうしないとは約束しません

ええと、それはcopyがインライン化される方法と関係があります。 noalias関数属性は、次のようなロードおよびストア命令で!alias.scopeおよび!noaliasメタデータに変換されます。

  %8 = load i32, i32* %0, align 4, !tbaa !8, !alias.scope !10, !noalias !13
  store i32 %8, i32* %7, align 4, !tbaa !8, !alias.scope !13, !noalias !10
  store i32 7, i32* %0, align 4, !tbaa !8, !alias.scope !10, !noalias !13

通常、関数が複数回インライン化される場合、各コピーはalias.scopeとnoaliasの独自の一意のIDを取得します。これは、各呼び出しがnoalias （ restrict （Cレベル）。呼び出しごとに値が異なる場合があります。

ただし、この場合、最初に関数がループにインライン化され、次にループが展開されるときにインライン化されたコードが複製されます。この複製によってIDは変更されません。 このため、LLVMは、のどれも考えていないa 'のいずれかの缶別名b 、偽である、s'を理由a第一及び第三の通話エイリアスから2番目の呼び出しからのbを使用します（すべて&mat[0]指します）。

驚くべきことに、GCCもこれを誤ってコンパイルし、出力が異なります。 （-O0でのclangとGCCは両方とも7 10出力します; -O3でのclangは7 7出力します; -O3でのGCCは10 7出力します。何かを台無しにして、結局UBを追加しますが、方法がわかりません...

*それよりも少し複雑ですが、この場合、 copyはポインタ演算を使用せず、両方のポインタに書き込むため、不等式a != bが必要であり、 UBになります。

ええ、同じ説明を見つけるために@nikicと競争したようです。 彼らのテストケースは少し良いです:)

それは本当に素晴らしいタイミングです^^同時にほぼ同じ削減されたテストケースで同じ結論に達しました:)

これを修正するには、おそらくhttps://github.com/llvm-mirror/llvm/blob/54d4881c352796b18bfe7314662a294754e3a752/lib/Transforms/Utils/InlineFunction.cpp#L801に沿った何かをLoopUnrollPassで実行する必要があります。

この問題のLLVMバグレポートをhttps://bugs.llvm.org/show_bug.cgi?id=39282に送信しました

そして、完全を期すためにこれに言及するだけで、Cテストケースも誤ってコンパイルされたため、バグレポートをGCCに送信しました： https ：//gcc.gnu.org/bugzilla/show_bug.cgi？id = 87609

トリアージ：これを正しく読んでいれば、LLVM修正が受け入れられました（https://reviews.llvm.org/D9375）。 それが実際にLLVMにマージすることの意味、またはそれがいつ起こったのかはわかりません。 LLVMの改訂プロセスに精通している人は、問題が今修正されているかどうか（およびどのバージョンか）を確認する必要があります。

それはマージされておらず、レビュープロセスは少し奇妙で、それをOKした人はもうパッチをレビューしません。

https://reviews.llvm.org/D68484

「完全制限」パッチセットを使用して必要があります。 このパッチセットが適用されているllvmの上で、誰かがRustでnoaliasを再度有効にしようとした場合はおそらく価値があります。

私はそれをやろうと思っています。
適度に強力なサーバー（48 HTコア、128GのRAM）にアクセスでき、パッチを使用してすべてを正しく構築できると思います。
動作するツールチェーンができたら、どのクレートを試すことをお勧めしますか？

llvmのアップストリームマスターですべてのrust固有のコミットをマージし終えてから、パッチを適用しました。
結果のブランチは次のとおりです： https ：
ツールチェーンをコンパイルして試してみましょう

まず、 https ：

最初に試すのに適した方法は、次のようなものです。

pub fn adds(a: &mut i32, b: &mut i32) {
    *a += *b;
    *a += *b;
}

そして、それが次のようなものにコンパイルされることを確認します。

example::adds:
        mov     eax, dword ptr [rsi]
        add     eax, eax
        add     dword ptr [rdi], eax
        ret

ではなく

example::adds:
        mov     eax, dword ptr [rdi]
        add     eax, dword ptr [rsi]
        mov     dword ptr [rdi], eax
        add     eax, dword ptr [rsi]
        mov     dword ptr [rdi], eax
        ret

次に、 https： //github.com/rust-lang/rust/issues/54462#issue-362850708のコードが誤ってコンパイルされていないことを確認します。

@ jrmuizel ＃54639には、新しいコンパイラテストとして＃54462用の@nagisaの最小限の再現機能が

AFAIKはデフォルトのフラグ（ -Zmutable-noalias=yesでオーバーライドできます）を変更するだけであり、前述のテストファイルを手動でコンパイルできるため、これを含めるかどうかは重要ではないと思います。

ご存知のとおり、私はまだLLVMをビルドしようとしていますが、現時点では、rust固有のパッチが適用されているかどうかに関係なくコンパイルエラーが発生します（つまり、アップストリームのllvmマスターとパッチも失敗します）。

In file included from /usr/include/c++/8/cmath:45,
                 from /opt/rust/src/llvm-project/llvm/include/llvm-c/DataTypes.h:28,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/Support/DataTypes.h:16,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/ADT/Hashing.h:47,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/ADT/ArrayRef.h:12,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/Transforms/Utils/NoAliasUtils.h:16,
                 from /opt/rust/src/llvm-project/llvm/lib/Transforms/Utils/NoAliasUtils.cpp:13:
/opt/rust/src/llvm-project/llvm/lib/Transforms/Utils/NoAliasUtils.cpp: In function ‘void llvm::cloneNoAliasScopes(llvm::ArrayRef<llvm::MetadataAsValue*>, llvm::DenseMap<llvm::MDN
ode*, llvm::MDNode*>&, llvm::DenseMap<llvm::MetadataAsValue*, llvm::MetadataAsValue*>&, llvm::StringRef, llvm::LLVMContext&)’:
/opt/rust/src/llvm-project/llvm/lib/Transforms/Utils/NoAliasUtils.cpp:174:30: error: no matching function for call to ‘llvm::AliasScopeNode::AliasScopeNode(double)’
         llvm::AliasScopeNode SNAN(MD);
                              ^~~~
In file included from /opt/rust/src/llvm-project/llvm/include/llvm/IR/TrackingMDRef.h:16,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/IR/DebugLoc.h:17,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/IR/Instruction.h:21,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/IR/BasicBlock.h:22,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/IR/Instructions.h:27,
                 from /opt/rust/src/llvm-project/llvm/include/llvm/Transforms/Utils/NoAliasUtils.h:22,
                 from /opt/rust/src/llvm-project/llvm/lib/Transforms/Utils/NoAliasUtils.cpp:13:
/opt/rust/src/llvm-project/llvm/include/llvm/IR/Metadata.h:1446:12: note: candidate: ‘llvm::AliasScopeNode::AliasScopeNode(const llvm::MDNode*)’
   explicit AliasScopeNode(const MDNode *N) : Node(N) {}
            ^~~~~~~~~~~~~~
/opt/rust/src/llvm-project/llvm/include/llvm/IR/Metadata.h:1446:12: note:   no known conversion for argument 1 from ‘double’ to ‘const llvm::MDNode*’
/opt/rust/src/llvm-project/llvm/include/llvm/IR/Metadata.h:1445:3: note: candidate: ‘constexpr llvm::AliasScopeNode::AliasScopeNode()’
   AliasScopeNode() = default;
   ^~~~~~~~~~~~~~
/opt/rust/src/llvm-project/llvm/include/llvm/IR/Metadata.h:1445:3: note:   candidate expects 0 arguments, 1 provided
/opt/rust/src/llvm-project/llvm/include/llvm/IR/Metadata.h:1441:7: note: candidate: ‘constexpr llvm::AliasScopeNode::AliasScopeNode(const llvm::AliasScopeNode&)’
 class AliasScopeNode {
       ^~~~~~~~~~~~~~
/opt/rust/src/llvm-project/llvm/include/llvm/IR/Metadata.h:1441:7: note:   no known conversion for argument 1 from ‘double’ to ‘const llvm::AliasScopeNode&’
/opt/rust/src/llvm-project/llvm/include/llvm/IR/Metadata.h:1441:7: note: candidate: ‘constexpr llvm::AliasScopeNode::AliasScopeNode(llvm::AliasScopeNode&&)’
/opt/rust/src/llvm-project/llvm/include/llvm/IR/Metadata.h:1441:7: note:   no known conversion for argument 1 from ‘double’ to ‘llvm::AliasScopeNode&&’
/opt/rust/src/llvm-project/llvm/lib/Transforms/Utils/NoAliasUtils.cpp:177:31: error: request for member ‘getName’ in ‘__builtin_nans(((const char*)""))’, which is of non-class ty
pe ‘double’
         auto ScopeName = SNAN.getName();
                               ^~~~~~~
/opt/rust/src/llvm-project/llvm/lib/Transforms/Utils/NoAliasUtils.cpp:187:39: error: request for member ‘getDomain’ in ‘__builtin_nans(((const char*)""))’, which is of non-class
type ‘double’
             const_cast<MDNode *>(SNAN.getDomain()), Name);
                                       ^~~~~~~~~
[ 75%] Building CXX object lib/Target/Hexagon/CMakeFiles/LLVMHexagonCodeGen.dir/RDFCopy.cpp.o
make[2]: *** [lib/Transforms/Utils/CMakeFiles/LLVMTransformUtils.dir/build.make:635: lib/Transforms/Utils/CMakeFiles/LLVMTransformUtils.dir/NoAliasUtils.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....

LLVMマスターがすでにパッチと同期していない可能性があり（パッチの大きさとLLVMマスターの移動速度を考慮すると発生する可能性があります）、LLVMマスターの古いリビジョンに対してビルドする必要がありますか？ これについてパッチの作成者にpingを送信することは間違いなく価値があります。

それはまさに私がやっていることであり、パッチでビルドされる古いリビジョンを見つけようとしています:-)

問題はllvm / masterにあるのではなく、パッチにあると確信しています。
まだパッチと互換性のあるllvm / masterからの最も古いコミットはhttps://github.com/llvm/llvm-project/commit/5b99c189b3bfc0faa157f7ca39652c0bb8c315a7ですが、それでもパッチのコンパイルに失敗します。
私は疲れすぎて怠惰で、今C ++を理解しようとはしていません。明日、もう一度やり直します。
それまでの間、誰かがパッチの作成者に連絡して助けを求めることはできますか？

rustllvmにパッチを適用せずに、（実際にビルドした後）RustでマスターLLVMを簡単に使用できるとは思いません。 AFAIKは、現在リリース6〜9のみをサポートしています。

@ mati865最初にrustのllvm-9フォークにパッチを適用しようとしましたが、それも簡単ではありませんでした...

パッチは明らかにllvm / llvm-project @ 82d3ba87d06f9e2abc6e27d8799587d433c56630の上にリベースされています。 その上に適用すると、それはあなたのために構築されますか？

@jrmuizelありがとう私はそれを試してみます！
それまでの間、私はrustllvmをllvmマスターでビルドするようにうまく適応させることができました。

@PaulGrandperrinにpingを

https://reviews.llvm.org/D68484

現実的に言えば、このパッチのサイズを考慮して、このパッチがマージされる予定のタイムラインと全体的な可能性はどのくらいですか？

@MSxDOSLLVM開発者に聞いてみてください。 一般に、パッチのサイズは、それがマージされるのを見たいという所有者の望みよりも重要ではないと思うので、質問するのは、LLVMがどれだけパッチが着地するのを見たいかということです。

これが私が見た最新のステータスです： https ：

https://github.com/bytecodealliance/cranelift ~~ https://github.com/bjorn3/rustc_codegen_craneliftがうまくいくと、ある時点で関連性が

@ leeoniya 、optビルドにcraneliftを使用する短期的な計画はありません。 クレーンリフトには、それを可能にするために必要な最適化作業がたくさんありません。

このオプションがないとエイリアシングが発生する可能性があると想定して、コンパイラがどれほど保守的であるかを知って驚いた。 例えば：

fn baz(s: &mut S) {
    if s.y < 10 {
        s.x = foo();
    }

    if s.y < 5 {
        s.x = foo();
    }
}

&mutを介して構造体メンバーにアクセスするため、 s.xとs.yがエイリアス可能であると想定し、 s.yに対して1回ではなく、2回のメモリアクセスが必要です。 通常のプログラムでメンバーが&mutを介して読み取り/書き込みを何回インターリーブする必要があるかを考えると、これは本当に残念なことです。

編集：いくつかのテストに基づくと、これはそのようなすべての読み取り/書き込みに影響を与えるとは思われません。これは、影響があった場合にパフォーマンスが低下する可能性があるため、驚くことではありません。 それでも、 -Z mutable-noalias使用すると、上記の例のダブルメモリアクセスが修正されるため、場合によっては無効になる可能性があります。

@PaulGrandperrinこのパッチの新しいバージョンがhttps://reviews.llvm.org/D69542にあり、 llvm @ 9fb46a452d4e5666828c95610ceac8dcd9e4ce16に基づいています。 もう一度実行してみませんか？