Full discussion: https://reviews.llvm.org/D74311
Fixed by rG15488ff24b4a
From the code review: "We probably want to backport the big-endian fix into 10.0 in some form?" Clement, can you help with this? I tried cherry-picking the whole commit over but it doesn't apply cleanly.
> Clement, can you help with this? I tried cherry-picking the whole commit > over but it doesn't apply cleanly. I guess the migration to typed Align() had not made it to 10.0. I'll need to do a manual merge. How can I get the patch to you afterwards (sorry, first time this happens to me) ? Thanks.
Created attachment 23122 [details] cherry-pick of rG15488ff24b4a on top of 10
(In reply to Clement Courbet from comment #5) > Created attachment 23122 [details] > cherry-pick of rG15488ff24b4a on top of 10 Thanks! Pushed that as b3cf70427eb1e97d9b89ba6e9298c280c8a32c74
I’m seeing a failure related to the relevant commit on the release/10.x branch (b3cf70427eb1e97d9b89ba6e9298c280c8a32c74). Specifically, I see a failure in the test “Transforms/CodeGenPrepare/PowerPC/split-store-alignment.ll”. Here are the results from me locally running this: apl@apl-mbp ~/code/llvm-project/build (release/10.x) $ ./bin/llvm-lit -sv test/Transforms/CodeGenPrepare/PowerPC FAIL: LLVM :: Transforms/CodeGenPrepare/PowerPC/split-store-alignment.ll (1 of 1) ******************** TEST 'LLVM :: Transforms/CodeGenPrepare/PowerPC/split-store-alignment.ll' FAILED ******************** Script: -- : 'RUN: at line 2'; /Users/apl/code/llvm-project/build/bin/opt -S -codegenprepare -mtriple=powerpc64-unknown-linux-gnu -data-layout="E-m:e-i64:64-n32:64" -force-split-store < /Users/apl/code/llvm-project/llvm/test/Transforms/CodeGenPrepare/PowerPC/split-store-alignment.ll | /Users/apl/code/llvm-project/build/bin/FileCheck --check-prefixes=ALL,BE /Users/apl/code/llvm-project/llvm/test/Transforms/CodeGenPrepare/PowerPC/split-store-alignment.ll : 'RUN: at line 3'; /Users/apl/code/llvm-project/build/bin/opt -S -codegenprepare -mtriple=powerpc64le-unknown-linux-gnu -data-layout="e-m:e-i64:64-n32:64" -force-split-store < /Users/apl/code/llvm-project/llvm/test/Transforms/CodeGenPrepare/PowerPC/split-store-alignment.ll | /Users/apl/code/llvm-project/build/bin/FileCheck --check-prefixes=ALL,LE /Users/apl/code/llvm-project/llvm/test/Transforms/CodeGenPrepare/PowerPC/split-store-alignment.ll -- Exit Code: 1 Command Output (stderr): -- /Users/apl/code/llvm-project/llvm/test/Transforms/CodeGenPrepare/PowerPC/split-store-alignment.ll:12:12: error: BE-NEXT: expected string not found in input ; BE-NEXT: [[TMP1:%.*]] = bitcast i64* [[P:%.*]] to i32* ^ <stdin>:12:2: note: scanning from here store i64 %o, i64* %p, align 1 ^ /Users/apl/code/llvm-project/llvm/test/Transforms/CodeGenPrepare/PowerPC/split-store-alignment.ll:48:12: error: BE-NEXT: expected string not found in input ; BE-NEXT: [[TMP1:%.*]] = bitcast i64* [[P:%.*]] to i32* ^ <stdin>:22:2: note: scanning from here store i64 %o, i64* %p, align 2 ^ /Users/apl/code/llvm-project/llvm/test/Transforms/CodeGenPrepare/PowerPC/split-store-alignment.ll:84:12: error: BE-NEXT: expected string not found in input ; BE-NEXT: [[TMP1:%.*]] = bitcast i64* [[P:%.*]] to i32* ^ <stdin>:32:2: note: scanning from here store i64 %o, i64* %p, align 8 ^ -- ******************** It looks like the test is expecting to see several things between the or and the store but running the first invocation of opt yields this: define void @split_store_align1(float %x, i64* %p) { %b = bitcast float %x to i32 %z = zext i32 0 to i64 %s = shl nuw nsw i64 %z, 32 %z2 = zext i32 %b to i64 %o = or i64 %s, %z2 store i64 %o, i64* %p, align 1 ret void }
(posting that on behalf of a coworker who doesn't have a Bugzilla account yet, but it's blocking our internal integration of 10.0)
That's strange. The test passes on my machine, and the output of the first run line looks like this: $ /work/llvm.monorepo.rel/build.release/bin/opt -S -codegenprepare -mtriple=powerpc64-unknown-linux-gnu -data-layout="E-m:e-i64:64-n32:64" -force-split-store < /work/llvm.monorepo.rel/llvm/test/Transforms/CodeGenPrepare/PowerPC/split-store-alignment.ll | head -19 ; ModuleID = '<stdin>' source_filename = "<stdin>" target datalayout = "E-m:e-i64:64-n32:64" target triple = "powerpc64-unknown-linux-gnu" define void @split_store_align1(float %x, i64* %p) { %b = bitcast float %x to i32 %z = zext i32 0 to i64 %s = shl nuw nsw i64 %z, 32 %z2 = zext i32 %b to i64 %o = or i64 %s, %z2 %1 = bitcast i64* %p to i32* %2 = getelementptr i32, i32* %1, i32 1 store i32 %b, i32* %2, align 1 %3 = bitcast i64* %p to i32* store i32 0, i32* %3, align 1 ret void } Could it be due to a difference in host architecture or build configuration or something?
Hm. I think I know what's happening. Are you by any chance compiling without support for PowerPC ? I just noticed that I failed to backport the base commit for the change, which included the addition of the local lit config checking for PowerPC targets.
Indeed, I could reproduce by compiling only with X86 support. I have committed be45a5a4092d678c992ac5d32e4b41da9367989a, which fixes the issue on my machine.
(In reply to Clement Courbet from comment #11) > Indeed, I could reproduce by compiling only with X86 support. > I have committed be45a5a4092d678c992ac5d32e4b41da9367989a, which fixes the > issue on my machine. Thanks!
Yup, we weren't enabling the PowerPC target. Thanks for the fix!