[PATCH] D37467: Add a new pass to speculate around PHI nodes with constant (integer) operands when profitable.

Chandler Carruth via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Sep 5 04:34:09 PDT 2017


chandlerc created this revision.
Herald added subscribers: eraman, fhahn, mgorny, mcrosier, mehdi_amini.
Herald added a reviewer: dberlin.

The core idea is to (re-)introduce some redundancies where their cost is
hidden by the cost of materializing immediates for constant operands of
PHI nodes. When the cost of the redundancies is covered by this,
avoiding materializing the immediate has numerous benefits:

1. Less register pressure
2. Potential for further folding / combining
3. Potential for more efficient instructions due to immediate operand

As a motivating example, consider the remarkably different cost on x86
of a SHL instruction with an immediate operand versus a register
operand.

This pattern turns up surprisingly frequently, but is somewhat rarely
obvious as a significant performance problem.

The pass is entirely target independent, but it does rely on the target
cost model in TTI to decide when to speculate things around the PHI
node. I've included x86-focused tests, but any target that sets up its
immediate cost model should benefit from this pass.

There is probably more that can be done in this space, but the pass
as-is is enough to get some important performance on our internal
benchmarks, and should be generally performance neutral, but help with
more extensive benchmarking is always welcome.

One awkward part is that this pass has to be scheduled after
*everything* that can eliminate these kinds of redundancies. This
includes SimplifyCFG, GVN, etc. I'm open to suggestions about better
places to put this. We could in theory make it part of the codegen pass
pipeline, but there doesn't really seem to be a good reason for that --
it isn't "lowering" in any sense and only relies on pretty standard cost
model based TTI queries, so it seems to fit well with the "optimization"
pipeline model. Still, further thoughts on the pipeline position are
welcome.

I've also only implemented this in the new pass manager. If folks are
very interested, I can try to add it to the old PM as well, but I didn't
really see much point (my use case is already switched over to the new
PM).

I have some testing in place, but can probably add some more. However,
I've built a reasonable amount of code with this pass enabled (test
suite, SPEC, and a decent pile of internal code).


https://reviews.llvm.org/D37467

Files:
  include/llvm/Transforms/Scalar/SpeculateAroundPHIs.h
  lib/Passes/PassBuilder.cpp
  lib/Passes/PassRegistry.def
  lib/Transforms/Scalar/CMakeLists.txt
  lib/Transforms/Scalar/SpeculateAroundPHIs.cpp
  test/Other/new-pm-defaults.ll
  test/Other/new-pm-thinlto-defaults.ll
  test/Transforms/SpeculateAroundPHIs/X86/basic.ll
  test/Transforms/SpeculateAroundPHIs/X86/lit.local.cfg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D37467.113835.patch
Type: text/x-patch
Size: 48522 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170905/f376f483/attachment.bin>


More information about the llvm-commits mailing list