This is an archive of the discontinued LLVM Phabricator instance.

Uses function-relative jump table encodings on PowerPC64
ClosedPublic

Authored by joerg on Nov 6 2016, 3:04 PM.

Details

Summary

Currently, the 64bit PowerPC port defaults to the generic jump table handling, which is not PIC. This patch implements the minimal platform specific version of D26018 for PPC64. Jump tables are encoded as GlobalBaseReg-relative 32bit offsets. This should work well both or large code models as well, assuming individual functions are still within 4GB.

The downside is that the current implementation requires the global base setup (two instructions) and one instruction more for the jump table branch. The former can likely be improved using a TOC-based pointer load, but that's outside the scope of this patch.

From a discussion on IRC, the TOC is not guaranteed to stay as continuous chunk, otherwise the jump table could directly be lowered unto the TOC at the cost of a larger table but without the instruction overhead.

Diff Detail

Repository
rL LLVM

Event Timeline

joerg updated this revision to Diff 76994.Nov 6 2016, 3:04 PM
joerg retitled this revision from to Uses function-relative jump table encodings on PowerPC64.
joerg updated this object.
joerg added reviewers: hfinkel, nadav, wschmidt.
joerg set the repository for this revision to rL LLVM.
joerg updated this revision to Diff 77984.Nov 15 2016, 5:37 AM
joerg removed rL LLVM as the repository for this revision.

Simplify the jump table handling. For PPC64, always use relative jump tables with the new hook from r286951. For the default, small and medium code model, use the existing difference from the jump table towards the label. For all other code models, setup the picbase and use the difference between the picbase and the block address.

Overall, this results in smaller data tables at the expensive of one more arithmetic operation. Given that we only create jump tables for more than two entries, it is a net win in size. For large code model, the only remaining assumption is that individual functions are no larger than 2GB.

hfinkel edited edge metadata.Nov 15 2016, 7:51 AM

Please post patches with full context.

lib/Target/PowerPC/PPCISelLowering.cpp
2190 ↗(On Diff #77984)

Please add a comment here explaining why we always use relative jump tables, even in non-PIC mode.

2194 ↗(On Diff #77984)

No need for this blank line.

2199 ↗(On Diff #77984)

The logic here seems unnecessarily complex. Please just do:

if (!Subtarget.isPPC64() || getTargetMachine().getCodeModel() != CodeModel::Large)
  return TargetLowering::getPICJumpTableRelocBase(Table, DAG);

return DAG.getNode(PPCISD::GlobalBaseReg, SDLoc(),
                     getPointerTy(DAG.getDataLayout()));
2212 ↗(On Diff #77984)

Please separate the function definitions with a blank line.

2216 ↗(On Diff #77984)

Regarding logic complexity, please refactor as for the function above.

joerg updated this revision to Diff 78066.Nov 15 2016, 1:36 PM
joerg edited edge metadata.

Add comment on why the relative encoding is always useful on PPC64. Fix formatting.

joerg marked 3 inline comments as done.Nov 15 2016, 1:39 PM
joerg added inline comments.
lib/Target/PowerPC/PPCISelLowering.cpp
2199 ↗(On Diff #77984)

I disagree. The reason for keeping the branches separate is to make it easier to see that PPC32 always gets the default behavior.

It is not just the large code model that has to be handled carefully here, but also JIT. I don't even know what guarantees the (potential) kernel code model would provide.

2216 ↗(On Diff #77984)

Same as above.

hfinkel accepted this revision.Nov 15 2016, 2:05 PM
hfinkel edited edge metadata.

LGTM

lib/Target/PowerPC/PPCISelLowering.cpp
2184 ↗(On Diff #78066)

Bit -> bits

Add a period after instructions.

2199 ↗(On Diff #77984)

Okay.

This revision is now accepted and ready to land.Nov 15 2016, 2:05 PM
joerg added inline comments.Nov 15 2016, 4:01 PM
lib/Target/PowerPC/PPCISelLowering.cpp
2184 ↗(On Diff #78066)

First done, second not. The sentence is not done at that point. I'm not sure if we actually ever create multiple jumps via the same jump table, but let's not rule that part out complete :)

This revision was automatically updated to reflect the committed changes.