Missing support
===============

* The PNaCl LLVM backend expands shufflevector operations into sequences of
  insertelement and extractelement operations. For instance:

    define <4 x i32> @shuffle(<4 x i32> %arg1, <4 x i32> %arg2) {
    entry:
      %res = shufflevector <4 x i32> %arg1,
                           <4 x i32> %arg2,
                           <4 x i32> <i32 4, i32 5, i32 0, i32 1>
      ret <4 x i32> %res
    }

  gets expanded into:

    define <4 x i32> @shuffle(<4 x i32> %arg1, <4 x i32> %arg2) {
    entry:
      %0 = extractelement <4 x i32> %arg2, i32 0
      %1 = insertelement <4 x i32> undef, i32 %0, i32 0
      %2 = extractelement <4 x i32> %arg2, i32 1
      %3 = insertelement <4 x i32> %1, i32 %2, i32 1
      %4 = extractelement <4 x i32> %arg1, i32 0
      %5 = insertelement <4 x i32> %3, i32 %4, i32 2
      %6 = extractelement <4 x i32> %arg1, i32 1
      %7 = insertelement <4 x i32> %5, i32 %6, i32 3
      ret <4 x i32> %7
    }

  Subzero should recognize these sequences and recombine them into
  shuffle operations where appropriate.

* Add support for vector constants in the backend. The current code
  materializes the vector constants it needs (eg. for performing icmp on
  unsigned operands) using register operations, but this should be changed to
  loading them from a constant pool if the register initialization is too
  complicated (such as in TargetX8632::makeVectorOfHighOrderBits()).

* [x86 specific] llvm-mc does not allow lea to take a mem128 memory operand
  when assembling x86-32 code. The current InstX8632Lea::emit() code uses
  Variable::asType() to convert any mem128 Variables into a compatible memory
  operand type. However, the emit code does not do any conversions of
  OperandX8632Mem, so if an OperandX8632Mem is passed to lea as mem128 the
  resulting code will not assemble.  One way to fix this is by implementing
  OperandX8632Mem::asType().

* [x86 specific] Lower shl with <4 x i32> using some clever float conversion:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100726/105087.html

* [x86 specific] Add support for using aligned mov operations (movaps). This
  will require passing alignment information to loads and stores.

x86 SIMD Diversification
========================

* Vector "bitwise" operations have several variant instructions: the AND
  operation can be implemented with pand, andpd, or andps. This pattern also
  holds for ANDN, OR, and XOR.

* Vector "mov" instructions can be diversified (eg. movdqu instead of movups)
  at the cost of a possible performance penalty.

* Scalar FP arithmetic can be diversified by performing the operations with the
  vector version of the instructions.