Shufflevector & InstCombine

James Molloy james at jamesmolloy.co.uk
Mon Aug 5 10:45:22 PDT 2013


Hi,

I was fiddling around today with InstCombine, trying to get it to combine
shufflevectors a bit more cleverly. I came across the following comment
which worried me somewhat:

  // Here we are really conservative:
  // we are absolutely afraid of producing a shuffle mask not in the input
  // program, because the code gen may not be smart enough to turn a merged
  // shuffle into two specific shuffles: it may produce worse code.  As
such,
  // we only merge two shuffles if the result is either a splat or one of
the
  // input shuffle masks.  In this case, merging the shuffles just removes
  // one instruction, which we know is safe.

Now, there are many clever things InstCombine could do with shufflevector.
The two I have in my queue at the moment are:
  1) Where there's an insertelement into vector B that comes direct from an
extractelement of vector A, and vector A's length is less than vector B's,
create a shuffle to extend A then another shuffle to perform the equivalent
of extract/insertelement.
  2) Where two shuffles' masks could combine to make a monotonically
increasing sequence, perform the combination.

Both of the above have caveats that can't be said in one sentence, but
they're basically rewriting common front-end patterns to make shuffles that
correspond to vector extension (VEXT instructions in ARM) or concatenation
of subvectors.

Now, I think these would both be of use to any architecture that has decent
shufflevector support, and InstCombine seems like the right place for it.
But if InstCombine is supposed to be conservative, where should these
optimizations go?

I remember Chandler being a bit worried by similar target-specific stuff
going in to InstSimplify - is InstCombine similar in that it's meant to
only canonicalise?

Input would be helpful :)

Cheers,

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130805/bbc0740c/attachment.html>


More information about the llvm-commits mailing list