Thumb 2 Instruction encoding problem: pc is not encoded properly #11592
Description
| Bugzilla Link | 11220 |
| Resolution | FIXED |
| Resolved on | Oct 24, 2011 19:21 |
| Version | trunk |
| OS | Windows NT |
| Attachments | the .bc file |
| Reporter | LLVM Bugzilla Contributor |
| CC | @asl |
Extended Description
2.9 did not have this problem, and this seriously broke my code. I don't know if it breaks anyone else's, but I have included the .bc file for testing purposes.
This gives the correct code:
llc -O2 -mtriple=thumb-none-eabi -mcpu=cortex-m3 -filetype=asm -o=BugOpt.asm BugOpt.bc
This, round tripped back through GNU Disasm (ALSO tested with Keil uVision) gives the wrong code:
llc -O2 -mtriple=thumb-none-eabi -mcpu=cortex-m3 -filetype=obj -o=BugOpt.obj BugOpt.bc
From this, I conclude it's probably an instruction encoding problem (hopefully an easy fix? :)
Round tripped, I get:
2c: e92d 48f0 stmdb sp!, {r4, r5, r6, r7, fp, lr}
54: e8bd 08f0 ldmiane.w sp!, {r4, r5, r6, r7, fp}
140: e8bd 08f0 ldmia.w sp!, {r4, r5, r6, r7, fp}
From the .asm, I get, for these same lines:
push.w {r4, r5, r6, r7, r11, lr}
popne.w {r4, r5, r6, r7, r11, pc}
pop.w {r4, r5, r6, r7, r11, pc}
I used Keil uVision to verify the round-tripping problem wasn't a bug in GNU Disasm. It shows POPNE and POP instead of GNU Disasm's ldmiane and ldmia, but the same problem: PC is not getting encoded for POP in this code.
Have a look at POP:
e8bd 08f0
11101 00010 1 1 1101 000 0100011110000
^ LLVM has forgotten to encode 1 for the PC.
The end result is that these functions do not return, but all of their registers are corrupted, and the code faults.
Please fix this. I'd really love to be able to upgrade to 3.0.
Thanks
James