I've recently changed the XCore target to implement BR_JT as a jump to a series jumps. The jump table entries are expand inline in the function so there is no longer a need to emit jump tables at the end of the function. However the emission of jump tables at the end of a function is done inside the AsmPrinter base class and there seems to be no way of disabling this.
This also seems to effect code produced for ARM Thumb2. Again each jump table is emitted twice - once inline in the code and once at the end of the function. The jump tables at the end of the function are unused.
What would be the preferred way of dealing with this? Should I add a variable to AsmPrinter that can be set by targets to disable this emission at the end?
The attached patch adds a bool to MCAsmInfo that can be used to disable the emission of jump tables at the end of a function and updates the XCore target to set this. Is this OK to commit?
inline_jt.patch (1.97 KB)
Hi Richard,
This shouldn't go into MCAsmInfo, it's a "lowering" issue, not a "assembly syntax" issue. ARM also has inline jump tables, how does it work?
-Chris
I've attached the result of running llc -march=arm on test/CodeGen/XCore/switch.ll. The jump table entries are emitted twice, once inside the function after the label .LJTI1_0_0 and then again outside the function after the label .LJTI1_0. The .LJTI1_0 label at the start of the second set of jumptable entries is completely unreferenced.
Given that MCAsmInfo is the wrong place would it make sense to describe it instead as a separate type of jump table encoding and add it to the MachineJumpTableInfo::JTEntryKind enum?
switch.s (924 Bytes)
I've recently changed the XCore target to implement BR_JT as a jump to a
series jumps. The jump table entries are expand inline in the function
so there is no longer a need to emit jump tables at the end of the
function. However the emission of jump tables at the end of a function
is done inside the AsmPrinter base class and there seems to be no way of
disabling this.
This also seems to effect code produced for ARM Thumb2. Again each jump
table is emitted twice - once inline in the code and once at the end of
the function. The jump tables at the end of the function are unused.
What would be the preferred way of dealing with this? Should I add a
variable to AsmPrinter that can be set by targets to disable this
emission at the end?
The attached patch adds a bool to MCAsmInfo that can be used to disable the emission of jump tables at the end of a function and updates the XCore target to set this. Is this OK to commit?
Hi Richard,
This shouldn't go into MCAsmInfo, it's a "lowering" issue, not a "assembly syntax" issue. ARM also has inline jump tables, how does it work?
-Chris
I've attached the result of running llc -march=arm on test/CodeGen/XCore/switch.ll. The jump table entries are emitted twice, once inside the function after the label .LJTI1_0_0 and then again outside the function after the label .LJTI1_0. The .LJTI1_0 label at the start of the second set of jumptable entries is completely unreferenced.
Interesting. Any idea when that started happening? I'm pretty sure that didn't used to be the case.
-Jim
On ARM the problem started after this commit:
http://llvm.org/viewvc/llvm-project?view=rev&revision=94719
I've attached a new patch which adds a new jump table encoding type to indicate jump
tables are emitted inline. This fixes the problem on the XCore target.
I can put together a patch to switch over ARM as well but I can't easily test it. After this the TargetJITInfo::hasCustomJumpTables() hook would no longer be needed and could be removed.
jt.patch (4.21 KB)
Typo "responisbility", otherwise looks great to me, please apply. For ARM, please just file a bugzilla suggesting that the ARM backend adopt this. Thanks Richard!
-Chris
Thanks for reviewing this. Committed in r98255 and r98256. The bug against the ARM backend is 6581:
http://llvm.org/bugs/show_bug.cgi?id=6581
Thanks, Richard. I'll have a look at that PR.
-jim