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>
Renato Golin
2015-Jul-06 12:39 UTC
[LLVMdev] ARM Jump table pcrelative relaxation in clang / llc
On 6 July 2015 at 07:18, Eric Bentura <ebentura at gmail.com> wrote:> 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?Hi Eric, First, I'd make sure if Tim's fix works for you. If you can't forward port your pass to trunk, try to backport Tim's patch into your tree.> 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.This is good news, means that the problem is probably not in the asm/obj emitters. The difference in behaviour between llc and clang are normally due to target description issues, as Tim mentioned. I'd encourage you to check on llc's object file and see how the jump table is being lowered. It's possible that the lack of a few flags clang passes to the back-end made that instruction not be selected during ISel. Essentially, "clang -target armv5t" is *not* the same as "llc -mtriple armv5t". I'm guessing you're hitting the same bug Tim found earlier... cheers, --renato
Eric Bentura
2015-Jul-06 18:13 UTC
[LLVMdev] ARM Jump table pcrelative relaxation in clang / llc
It is certainly helping - Thanks Renato. 2015-07-06 18:39 GMT+03:00 Renato Golin <renato.golin at linaro.org>:> On 6 July 2015 at 16:32, Eric Bentura <ebentura at gmail.com> wrote: > > I tried to build the object file using clang 3.7 and it fails with the > same > > error. > > Where should I look at in the ARM backend to understand what happens? > > Where the jump table instruction is generated and supposed to be relaxed? > > Have a look at lib/Target/ARM/ARMConstantIslandPass.cpp, especially > where Tim's patch touches: > > http://llvm.org/viewvc/llvm-project?view=revision&revision=238680 > > Instruction relaxation rules should be in the TableGen files, I think, > but that means it could be in a number of places. > > Step through lib/Target/ARM/ARMAsmPrinter.cpp, at > ARMAsmPrinter::EmitJumpTableInsts and see what the operand is. > > You'd expect that it would be already relaxed by that point. If it is, > the bug is in the printer. If not, it could be in the instruction > selection process, either ARMISelLowering or during validation, at > ARMISelDAGToDAG. > > Hope that helps. > > cheers, > --renato >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150706/97f8827c/attachment.html>
Eric Bentura
2015-Jul-07 13:06 UTC
[LLVMdev] ARM Jump table pcrelative relaxation in clang / llc
I have created a small ll file to reproduce the problem. I used the intrinsic function llvm.arm.space to introduce space between the beginning of the code and the jump table. If the first argument of llvm.arm.space is higher than INT_MAX ( *2147483647)*, then the bug is hit. Lower or equal to that value, it passes. It looks like a precision issue. Does this sound familiar to someone? ; ModuleID = 'test.c' target datalayout = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64" target triple = "armv5e-none-linux-androideabi" declare i32 @llvm.arm.space(i32, i32) ; Function Attrs: nounwind define i32 @main() #0 { entry: %retval = alloca i32, align 4 %a = alloca i32, align 4 store i32 0, i32* %retval store i32 0, i32* %a, align 4 %0 = load i32* %a, align 4 call i32 @llvm.arm.space(i32* 2147483647*, i32 undef) switch i32 %0, label %sw.default [ i32 0, label %sw.bb i32 1, label %sw.bb1 i32 2, label %sw.bb2 i32 3, label %sw.bb3 ] sw.bb: ; preds = %entry store i32 1, i32* %retval br label %return sw.bb1: ; preds = %entry store i32 2, i32* %retval br label %return sw.bb2: ; preds = %entry store i32 3, i32* %retval br label %return sw.bb3: ; preds = %entry store i32 4, i32* %retval br label %return sw.default: ; preds = %entry br label %sw.epilog sw.epilog: ; preds = %sw.default store i32 0, i32* %retval br label %return return: ; preds = %sw.epilog, %sw.bb3, %sw.bb2, %sw.bb1, %sw.bb %2 = load i32* %retval ret i32 %2 } ; Function Attrs: nounwind declare i32 @rand() #0 attributes #0 = { nounwind "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" "use-soft-float"="true" } attributes #1 = { nounwind } !llvm.module.flags = !{!0, !1, !2} !llvm.ident = !{!3} !0 = !{i32 1, !"wchar_size", i32 4} !1 = !{i32 1, !"min_enum_size", i32 4} !2 = !{i32 1, !"PIC Level", i32 1} !3 = !{!"clang version 3.7.0 (trunk 229364)"} 2015-07-06 21:13 GMT+03:00 Eric Bentura <ebentura at gmail.com>:> It is certainly helping - Thanks Renato. > > 2015-07-06 18:39 GMT+03:00 Renato Golin <renato.golin at linaro.org>: > >> On 6 July 2015 at 16:32, Eric Bentura <ebentura at gmail.com> wrote: >> > I tried to build the object file using clang 3.7 and it fails with the >> same >> > error. >> > Where should I look at in the ARM backend to understand what happens? >> > Where the jump table instruction is generated and supposed to be >> relaxed? >> >> Have a look at lib/Target/ARM/ARMConstantIslandPass.cpp, especially >> where Tim's patch touches: >> >> http://llvm.org/viewvc/llvm-project?view=revision&revision=238680 >> >> Instruction relaxation rules should be in the TableGen files, I think, >> but that means it could be in a number of places. >> >> Step through lib/Target/ARM/ARMAsmPrinter.cpp, at >> ARMAsmPrinter::EmitJumpTableInsts and see what the operand is. >> >> You'd expect that it would be already relaxed by that point. If it is, >> the bug is in the printer. If not, it could be in the instruction >> selection process, either ARMISelLowering or during validation, at >> ARMISelDAGToDAG. >> >> Hope that helps. >> >> cheers, >> --renato >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150707/a158a1e2/attachment.html>