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: unassignedb...@nondot.org
Reporter: jholaj...@arxan.com
CC: htmldevelo...@gmail.com, llvm-bugs@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._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
