[PATCH] Change the policy of ZERO_EXTEND/SIGN_EXTEND for SelectionDAG builder and legalization
Jiangning Liu
liujiangning1 at gmail.com
Mon Aug 18 19:17:30 PDT 2014
Hi t.p.northover,
Hi Tim,
In SelectionDAG builder, we simply insert ZERO_EXTEND for CopyToReg if only TLI thinks ZERO_EXTEND is free.
This is not optimal if the virtual register has multiple compare instruction users crossing basic blocks.
The operand of a compare instruction could be promoted (extended) to be a signed/unsigned value if the predicate of the compare instruction IsSigned()/IsUnsigned. If multiple compare instructions use the same operand, we will unavoidably have conflict extension.
We have two optimization opportunities here,
1) If we know the number of signed predicate user is greater than unsigned, we prefer to use signed promotion, and we use zero promotion otherwise.
2) Predicates EQ and NE are neither signed nor unsigned, so they can be treated as either signed or unsigned. if know the incoming value is AssertSext, we should prefer to do signed promotion.
With those two optimizations, fewer signed/zero extension instructions can be inserted, and then we can expose more opportunities to Machine CSE pass in back-end.
For Cortex-A57, the following two benchmark performance improvements are observed.
spec.cpu2006.ref.470_lbm 1862.8973 -6.85%
spec.cpu2006.ref.444_namd 1549.8160 -5.43%
Thanks,
-Jiangning
http://reviews.llvm.org/D4967
Files:
lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp
lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
test/CodeGen/AArch64/atomic-ops.ll
test/CodeGen/AArch64/rm_redundant_cmp.ll
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D4967.12639.patch
Type: text/x-patch
Size: 11132 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140819/4aa410a0/attachment.bin>
More information about the llvm-commits
mailing list