[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