[llvm-commits] [llvm] r58964 - in /llvm/trunk: docs/LangRef.html lib/Bitcode/Reader/BitcodeReader.cpp lib/CodeGen/SelectionDAG/DAGCombiner.cpp lib/CodeGen/SelectionDAG/LegalizeDAG.cpp lib/CodeGen/SelectionDAG/LegalizeTypes.h lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp lib/CodeGen/SelectionDAG/SelectionDAG.cpp lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp lib/Transforms/Scalar/InstructionCombining.cpp lib/VMCore/ConstantFold.cpp lib/VMCore/Instructions.cpp lib/VMCore/Verifier.cpp

[Duncan Sands]

Hi Mon Ping,

> I like this implementation in general and you capture a case that I  
> missed (in avoid using build vector) :-> .   In my thinking (which is  
> why I went more for a prescan methodology), the typical case is when  
> we can use split vectors for the new shuffle.  So pre splitting the  
> vectors seems fine as we will using some of the result of the presplit  
> in the vector shuffle.  I don't particular like prebuilding the  
> BuildOps though because we build a set of extract element nodes that  
> we will typically throw away. It seems a little cleaner to me to  
> iterate through the mask again and build these nodes when we need  
> them.  What do you think?

I don't much like this either, yet it seems a pity to duplicate the
logic, most of which is the same.  I decided to do it this way after
a small analysis of the probability of being able to make a vector
shuffle assuming that the original mask indices are uniformly randomly
distributed.  If the vector being split has length 2 or 4 then a vector
shuffle is always used.  However when splitting a vector of length 8, I
calculate that there is only about one chance in three that you can
construct a vector shuffle.  For length 16 this drops to one chance in
50.  Thus making build vector elements is only likely to be a waste of
time for vectors of length 2 or 4.  In these cases you construct either
2 or 4 pointless nodes.  This is not a big cost.

Ciao,

Duncan.