[PATCH] D36619: [MachineCombine] Update instruction depths incrementally.

Florian Hahn via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Aug 11 08:47:48 PDT 2017

fhahn created this revision.

I recently looked into a compile time problem where 80% of the compile
time (opt+codegen) was spent in MachineCombiner. Currently the
complete trace information for a basic block (and it's relevant
successors and predecessors) has to be re-computed each time to decide
if it is profitable to combine instructions. For certain input code
(large basic blocks with many combinable instructions),
machine-combine dominates the compile-time and most of the time is spent
re-computing trace information.

I was thinking about how we could avoid re-computing the trace
information over and over and this is a WIP patch with one idea. I'd appreciate
any ideas, thoughts and comments.

MachineCombine primarily uses the instruction depth to decide if combining is
profitable. As we already iterate
over all instructions in a basic block, the instruction depth can be computed
incrementally. This reduces the cost of machine-combine drastically in cases
where lots of instructions are combined. The major drawback is that
AFAIK, computing the critical path length cannot be done incrementally,
so this patch does not use the instruction slack in the cost
function. The unit tests do not contain any test cases that combine
instructions based on the slack and at least
on a Cortex-A72 there was no measurable performance difference with the
test suite, SPEC2000, SPEC2006 and a couple of proprietary benchmarks.
For X86, I used -stats to compare the number of combined instructions on
SPEC2000 and SPEC2006 and there is only a small difference in the
numbers (of course it could be that we do not combine instructions in
hot loops with this patch on X86).
Another option would be to only use the incremental update only in cases
where re-computing the trace info is very expensive, i.e. large basic
blocks and lots of instructions that can be combined.

What do you think?



-------------- next part --------------
A non-text attachment was scrubbed...
Name: D36619.110736.patch
Type: text/x-patch
Size: 13399 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170811/5aedb190/attachment.bin>

More information about the llvm-commits mailing list