This is an archive of the discontinued LLVM Phabricator instance.

[CodeGen] JumpMaps switch statement optimization (stub)
Needs ReviewPublic

Authored by MartaW on May 2 2017, 4:14 AM.

Details

Summary

The patch partially implements JumpMaps switch statement optimization (refer to "(RFC) JumpMaps: switch statement optimization" on llvm-dev).
The transformation is not fully implemented yet; the code is required for further discussion.
The JumpMaps emission is turned on with --enable-jump-maps flag (disabled by default).

Current caveats:

  1. no support for PIC model
  2. search functions are not created / linked automatically, the code generated with optimization needs to be manually linked to __jmfind_x_x functions which (not optimized and generic) implementation can be found in a temporary file jmdev/jmfind.c. The right solution for functions creation / calls / linking are to be discused.
  3. the analysis pass should be run on a module, not on a function. it is also not up to date with last changes to SelectionDAGBuilder and TargetLowering.
  4. No regression tests fail with JumpMaps disabled. 8 regression tests fails with enabled JumpMaps are expected and caused by either modifying switch statement lowering (JumpMaps change switches handling so, naturally, basic blocks and emitted code look different) or lack of support for PIC model yet. These tests are: LLVM :: CodeGen/Generic/MachineBranchProb.ll LLVM :: CodeGen/X86/branchfolding-catchpads.ll LLVM :: CodeGen/X86/early-ifcvt.ll LLVM :: CodeGen/X86/switch-bt.ll LLVM :: CodeGen/X86/switch-edge-weight.ll LLVM :: CodeGen/X86/switch.ll LLVM :: CodeGen/X86/tail-merge-unreachable.ll LLVM :: CodeGen/X86/x86-shrink-wrapping.ll

Diff Detail

Event Timeline

MartaW created this revision.May 2 2017, 4:14 AM
wwa added a subscriber: wwa.May 5 2017, 2:48 AM
MartaW edited the summary of this revision. (Show Details)May 8 2017, 3:56 AM

(I'm planning to look at this and add some comments; expect a reply next week.)

I like the general idea of jumpmaps as detailed on the mailinglist.

Can you motivate why this uses a new type of MachineOperand/ISDOpcode instead of somehow using just the existing JumpTable things?

wwa added a comment.May 22 2017, 4:12 AM

I suppose it could be done with JumpTable struct, given some additional data but I feel that it is much more clean and elegant with a separete one.
For instance, a target might need special lowering for JumpMaps but not JumpTables, so it could use TargetLowering::setOperationAction(ISD::JumpMap, Custom).
If JumpMaps and JumpTables are combined under a single ISD, then Target has to look into the struct to figure out how to handle it.

Having a separete ISD reuses the existing Lowering logic best.

I like the general idea of jumpmaps as detailed on the mailinglist.

Can you motivate why this uses a new type of MachineOperand/ISDOpcode instead of somehow using just the existing JumpTable things?