Eric Bentura
2015-Jul-05 14:22 UTC
[LLVMdev] ARM Jump table pcrelative relaxation in clang / llc
Hi, I have written a PassManager (IR) pass that seriously increases the size of the original IR code. As a result it seems that the generated machine code is incorrect (as of LLVM 3.5): The AsmPrinter generates the following instruction : adr r2, .LJTI4_0_0 when going through the MC streamer, I get a "fatal error: error in backend: out of range pc-relative fixup" . Apparently, the fixup does not hold in the 12 bits we have available. I would have expected clang to perform relaxation on this instruction on that particular case. Using the flag mrelax-all does not help. Is there a way in the PassManager::runOnFunction to anticipate that so that I can generate a IR code that would fit when converted to machine code? Strangely enough, this is not happening when using llc to generate the code from the bc file, I get the object file. The target is armv5e-none-linux-androideabi ( I used -mtriple with llc). I have seen a similar thread in 2012 " Questions on MachineFunctionPass and relaxation of pcrel calls (ARM/thumb2)". Even though there have been improvements since them, I am concerned with the difference of behavior of the two tools. Thanks for your help. Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150705/1c72df3e/attachment.html>
Tim Northover
2015-Jul-05 15:53 UTC
[LLVMdev] ARM Jump table pcrelative relaxation in clang / llc
Hi Eric, On 5 July 2015 at 07:22, Eric Bentura <ebentura at gmail.com> wrote:> As a result it seems that the generated machine code is incorrect (as of > LLVM 3.5): The AsmPrinter generates the following instruction : > adr r2, .LJTI4_0_0 > when going through the MC streamer, I get a "fatal error: error in backend: > out of range pc-relative fixup" .We've fairly recently fixed a bug that looks very similar (r238680, which was well after 3.6)> Apparently, the fixup does not hold in the 12 bits we have available. I > would have expected clang to perform relaxation on this instruction on that > particular case.Agreed, whatever's going on it's a bug in the ARM backend.> Is there a way in the PassManager::runOnFunction to anticipate that so that > I can generate a IR code that would fit when converted to machine code?Not as far as I'm aware; since the bug is further back there's no reason to try and provide such information to earlier passes. The backend is expected to cope with whatever you give it.> Strangely enough, this is not happening when using llc to generate the code > from the bc file, I get the object file.That's weird. Even with "-filetype=obj" (the bug only occurs when directly writing an object file)? Not that it really affects anything, getting the same backend options with llc can be a bit tricky.> Even though there have been > improvements since them, I am concerned with the difference of behavior of > the two tools.The most common one I find perturbing output is "-mcpu" (even with a triple), but really there are so many options front-ends can twiddle that you just have to know what it's doing and copy that. Cheers. Tim.
Eric Bentura
2015-Jul-06 06:18 UTC
[LLVMdev] ARM Jump table pcrelative relaxation in clang / llc
Hi Tim, Thank you for your answer. *We've fairly recently fixed a bug that looks very similar (r238680,which was well after 3.6)* If I wanted to back port that to 3.5 where should I look at? Where in the ARM backend the decision to relax an instruction is taken? *That's weird. Even with "-filetype=obj" (the bug only occurs whendirectly writing an object file)? Not that it really affects anything,getting the same backend options with llc can be a bit tricky.* This is passing even with -filetype=obj. The transformation I apply are in the optimizer so I must build the new bc to create the object file. Thanks for your help Eric Le dimanche 5 juillet 2015, Tim Northover <t.p.northover at gmail.com> a écrit :> Hi Eric, > > On 5 July 2015 at 07:22, Eric Bentura <ebentura at gmail.com> wrote: > > As a result it seems that the generated machine code is incorrect (as of > > LLVM 3.5): The AsmPrinter generates the following instruction : > > adr r2, .LJTI4_0_0 > > when going through the MC streamer, I get a "fatal error: error in > backend: > > out of range pc-relative fixup" . > > We've fairly recently fixed a bug that looks very similar (r238680, > which was well after 3.6) > > > Apparently, the fixup does not hold in the 12 bits we have available. I > > would have expected clang to perform relaxation on this instruction on > that > > particular case. > > Agreed, whatever's going on it's a bug in the ARM backend. > > > Is there a way in the PassManager::runOnFunction to anticipate that so > that > > I can generate a IR code that would fit when converted to machine code? > > Not as far as I'm aware; since the bug is further back there's no > reason to try and provide such information to earlier passes. The > backend is expected to cope with whatever you give it. > > > Strangely enough, this is not happening when using llc to generate the > code > > from the bc file, I get the object file. > > That's weird. Even with "-filetype=obj" (the bug only occurs when > directly writing an object file)? Not that it really affects anything, > getting the same backend options with llc can be a bit tricky. > > > Even though there have been > > improvements since them, I am concerned with the difference of behavior > of > > the two tools. > > The most common one I find perturbing output is "-mcpu" (even with a > triple), but really there are so many options front-ends can twiddle > that you just have to know what it's doing and copy that. > > Cheers. > > Tim. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150706/0547fdc8/attachment.html>
Maybe Matching Threads
- [LLVMdev] ARM Jump table pcrelative relaxation in clang / llc
- [LLVMdev] ARM Jump table pcrelative relaxation in clang / llc
- [LLVMdev] ARM Jump table pcrelative relaxation in clang / llc
- [klibc:riscv64-enable-relax] riscv64: Make linker relaxation work and enable it
- [klibc:riscv64-enable-relax] riscv64: Make linker relaxation work and enable it