[llvm-bugs] [Bug 38661] New: PPC32 fails to extend i1 in stack arguments

[via llvm-bugs]

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: unassignedbugs at nondot.org
          Reporter: jistone at redhat.com
                CC: llvm-bugs at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180821/f3342ea0/attachment.html>