https://bugs.llvm.org/show_bug.cgi?id=38661
Bug ID: 38661
Summary: PPC32 fails to extend i1 in stack arguments
Product: libraries
Version: trunk
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: PowerPC
Assignee: unassignedb...@nondot.org
Reporter: jist...@redhat.com
CC: llvm-bugs@lists.llvm.org
GitHub user @LionNatsu managed to reduce rust#50960 to a simple LLVM-IR test:
https://github.com/rust-lang/rust/issues/50960#issuecomment-414482775
target datalayout = "E-m:e-p:32:32-i64:64-n32"
target triple = "powerpc-unknown-linux-gnu"
declare zeroext i1 @a_strange_function(i1 zeroext, i1 zeroext, i1 zeroext,
i1 zeroext, i1 zeroext, i1 zeroext, i1 zeroext, i1 zeroext, i1 zeroext, i1
zeroext)
define i32 @main(i32, i8**) {
top:
%2 = call zeroext i1 @a_strange_function(i1 zeroext true, i1 zeroext
true, i1 zeroext true, i1 zeroext true, i1 zeroext true, i1 zeroext true, i1
zeroext true, i1 zeroext true, i1 zeroext true, i1 zeroext true)
ret i32 0
}
The call is generated like this:
li 3, 1
li 4, 1
li 5, 1
li 6, 1
stb 3, 12(1)
stb 3, 8(1)
li 3, 1
li 7, 1
li 8, 1
li 9, 1
li 10, 1
bl a_strange_function@PLT
Those "stb" should be "stw" to properly fill the "i1 zeroext" argument to i32,
as ABI requires. Otherwise we've only written the most-significant byte of the
full argument that the callee will read.
As it happens, Rust's callee was compiled with GCC, but we can also see a
problem in the function definition if compiled with LLVM. Something like:
define zeroext i1 @a_strange_function(i1 zeroext, i1 zeroext, i1 zeroext,
i1 zeroext, i1 zeroext, i1 zeroext, i1 zeroext, i1 zeroext, i1 zeroext, i1
zeroext) {
%result = and i1 %8, %9
ret i1 %result
}
This produces:
lbz 3, 12(1)
lbz 4, 8(1)
and 3, 4, 3
clrlwi 3, 3, 31
blr
Those "lbz" are bug-compatible with what the caller did above, but still wrong
for the ABI. It should either read the whole word, or just read the
least-significant bytes at 15(1) and 11(1).
These problems do not arise with "llc -O0" or "-O1", which also means these two
won't be bug-compatible if they're compiled with different optimization levels.
Of course they should both stick to ABI.
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
