[PATCH] D13551: [LoopVectorize] Shrink integer operations into the smallest type possible

James Molloy via llvm-commits llvm-commits at lists.llvm.org
Thu Oct 8 05:58:54 PDT 2015


jmolloy created this revision.
jmolloy added reviewers: sbaranga, hfinkel, gberry, anemet.
jmolloy added a subscriber: llvm-commits.
jmolloy set the repository for this revision to rL LLVM.
Herald added a subscriber: aemerson.

C semantics force sub-int-sized values (e.g. i8, i16) to be promoted to int
type (e.g. i32) whenever arithmetic is performed on them.

For targets with native i8 or i16 operations, usually InstCombine can shrink
the arithmetic type down again. However InstCombine refuses to create illegal
types, so for targets without i8 or i16 registers, the lengthening and
shrinking remains.

Most SIMD ISAs (e.g. NEON) however support vectors of i8 or i16 even when
their scalar equivalents do not, so during vectorization it is important to
remove these lengthens and truncates when deciding the profitability of
vectorization.

The algorithm this uses starts at truncs and icmps, trawling their use-def
chains until they terminate or instructions outside the loop are found (or
unsafe instructions like inttoptr casts are found). If the use-def chains
starting from different root instructions (truncs/icmps) meet, they are
unioned. The demanded bits of each node in the graph are ORed together to form
an overall mask of the demanded bits in the entire graph. The minimum bitwidth
that graph can be truncated to is the bitwidth minus the number of leading
zeroes in the overall mask.

The intention is that this algorithm should "first do no harm", so it will
never insert extra cast instructions. This is why the use-def graphs are
unioned, so that subgraphs with different minimum bitwidths do not need casts
inserted between them.

This algorithm works hard to reduce compile time impact. DemandedBits are only
queried if there are extends of illegal types and if a truncate to an illegal
type is seen. In the general case, this results in a simple linear scan of the
instructions in the loop.

No non-noise compile time impact was seen on a clang bootstrap build.

Repository:
  rL LLVM

http://reviews.llvm.org/D13551

Files:
  include/llvm/Analysis/VectorUtils.h
  lib/Analysis/VectorUtils.cpp
  lib/Transforms/Vectorize/LoopVectorize.cpp
  test/Transforms/LoopVectorize/AArch64/loop-vectorization-factors.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D13551.36848.patch
Type: text/x-patch
Size: 32175 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151008/7698ba54/attachment-0001.bin>


More information about the llvm-commits mailing list