AArch64 currently uses 64bit jump table entries for non-PIC mode. With this patch, it will use the same encoding for small/medium code models as the current PIC mode does. For other (larger) code models, the function itself is used as relocation base.
Details
Diff Detail
Event Timeline
Thanks for working on this. I think the approach is good, so just have a couple of minor comments on the implementation:
lib/Target/AArch64/AArch64ISelLowering.cpp | ||
---|---|---|
2322 | I think we should be explicit about what cases this covers. JITDefault, Kernel & Large? I didn't think we actually supported a Kernel model on AArch64, but I could sort of believe it wanted this. | |
2350–2351 | It looks like getTargetMachine().getSymbol(MF->getFunction()) would be correct (going via getOrCreateSymbol) and save stashing the symbol away in the FunctionInfo. |
lib/Target/AArch64/AArch64ISelLowering.cpp | ||
---|---|---|
2322 | I'm not attached to using default here, enumerating all code models works fine for me, too. The primary concern for me is that we are pessimistic in our assumptions, e.g. whether the 2GB difference works or not. | |
2350–2351 | TM::getSymbol needs access to the mangler. The implementation in AsmPrinter uses getObjFileLowering() for accessing that. It doesn't seem to be simpler that way. I'm consider whether the symbol should be stashed into the generic MachineFunction data, but that looks like an optimisation for a separate patch. |
lib/Target/AArch64/AArch64ISelLowering.cpp | ||
---|---|---|
2350–2351 | I still think the locality makes it simpler. Actually, I think it makes little sense for getSymbol to require a mangler. The implementation already goes most of the way towards getting one of its own (it has a TLOF local variable). I think I'll fix that this morning. |
I think we should be explicit about what cases this covers. JITDefault, Kernel & Large? I didn't think we actually supported a Kernel model on AArch64, but I could sort of believe it wanted this.