[llvm-bugs] [Bug 39714] New: -fast-isel=0 for armv7 can result in 4-byte Reload without corresponding 4-byte Spill

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=39714

            Bug ID: 39714
           Summary: -fast-isel=0 for armv7 can result in 4-byte Reload
                    without corresponding 4-byte Spill
           Product: new-bugs
           Version: 7.0
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: jholajter at arxan.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

Created attachment 21130
  --> https://bugs.llvm.org/attachment.cgi?id=21130&action=edit
repro.ll can be use to reproduce the incorrect assembly generated by llc

The attached test case demonstrates an issue where lowering armv7 bitcode for
iOS using -fast-isel=0 results in a register being reloaded from the stack
without first being spilled to the stack. This results in an unknown value
being loaded into the register and undefined runtime results.

This bug is important because Apple forces use of -fast-isel=0 when re-lowering
armv7 bitcode built using Enable Bitcode set to Yes. There is no way to disable
use of -fast-isel=0 when submitting bitcode to Apple.

Use the following command line with the attached repro.ll:
llc -relocation-model=pic -O0 -fast-isel=0 repro.ll -filetype=asm -o repro.s

The resultant repro.s will contain the following line:
        ldr.w   r1, [r6, #2500]         @ 4-byte Reload

The reload of r1 with r6 offset by #2500 was never spilled to the stack. This
instruction is reading and unknown value from the stack and populating r1 with
it. This leads to undefined runtime behavior.

>From the repro.ll file, you can see that a function named printAggregate() is
being invoked:
  call void @printAggregate(%struct.structOfStrings* byval align 4
@structOfStrings2, i32 2) #18
  call void @printAggregate(%struct.structOfStrings* byval align 4
@structOfStrings1, i32 1) #18
  call void @printAggregate(%struct.structOfStrings* byval align 4
@structOfStrings3, i32 3) #18


In the repro.s file, prior to the first invocation of printAggregate() we can
see that the second parameter is populated into r1 via the following
instruction:
        movs    r1, #2
This is also the case with the third invocation of printAggregate():
        movs    r1, #3
It is unclear why the second invocation of printAggregate() does not also use
movs, instead trying to Reload r1 from the stack even though it was never
spilled.

-- 
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/20181119/af1f0803/attachment.html>