Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CodeGenPrepare] Store splitting creates invalid alignments on big-endian targets, and under-aligned stores on all targets #44222

Closed
legrosbuffle opened this issue Feb 12, 2020 · 13 comments
Labels
bugzilla Issues migrated from bugzilla llvm:codegen

Comments

@legrosbuffle
Copy link
Contributor

Bugzilla Link 44877
Resolution FIXED
Resolved on Feb 19, 2020 09:46
Version trunk
OS Linux
Blocks #43900
CC @gchatelet,@zmodem,@LebedevRI,@smeenai,@rotateright
@legrosbuffle
Copy link
Contributor Author

Full discussion: https://reviews.llvm.org/D74311

@legrosbuffle
Copy link
Contributor Author

Fixed by rG15488ff24b4a

@zmodem
Copy link
Collaborator

zmodem commented Feb 12, 2020

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.

@legrosbuffle
Copy link
Contributor Author

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.

@legrosbuffle
Copy link
Contributor Author

@zmodem
Copy link
Collaborator

zmodem commented Feb 12, 2020

Created attachment 23122 [details]
cherry-pick of rG15488ff24b4a on top of 10

Thanks! Pushed that as b3cf704

@smeenai
Copy link
Collaborator

smeenai commented Feb 19, 2020

I’m seeing a failure related to the relevant commit on the release/10.x branch (b3cf704). 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
^
: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
^
: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
^
: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
}

@smeenai
Copy link
Collaborator

smeenai commented Feb 19, 2020

(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)

@zmodem
Copy link
Collaborator

zmodem commented Feb 19, 2020

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 = ''
source_filename = ""
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?

@legrosbuffle
Copy link
Contributor Author

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.

@legrosbuffle
Copy link
Contributor Author

Indeed, I could reproduce by compiling only with X86 support.
I have committed be45a5a, which fixes the issue on my machine.

@zmodem
Copy link
Collaborator

zmodem commented Feb 19, 2020

Indeed, I could reproduce by compiling only with X86 support.
I have committed be45a5a, which fixes the
issue on my machine.

Thanks!

@smeenai
Copy link
Collaborator

smeenai commented Feb 19, 2020

Yup, we weren't enabling the PowerPC target. Thanks for the fix!

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla llvm:codegen
Projects
None yet
Development

No branches or pull requests

3 participants