1Missing support 2=============== 3 4* The PNaCl LLVM backend expands shufflevector operations into sequences of 5 insertelement and extractelement operations. For instance: 6 7 define <4 x i32> @shuffle(<4 x i32> %arg1, <4 x i32> %arg2) { 8 entry: 9 %res = shufflevector <4 x i32> %arg1, 10 <4 x i32> %arg2, 11 <4 x i32> <i32 4, i32 5, i32 0, i32 1> 12 ret <4 x i32> %res 13 } 14 15 gets expanded into: 16 17 define <4 x i32> @shuffle(<4 x i32> %arg1, <4 x i32> %arg2) { 18 entry: 19 %0 = extractelement <4 x i32> %arg2, i32 0 20 %1 = insertelement <4 x i32> undef, i32 %0, i32 0 21 %2 = extractelement <4 x i32> %arg2, i32 1 22 %3 = insertelement <4 x i32> %1, i32 %2, i32 1 23 %4 = extractelement <4 x i32> %arg1, i32 0 24 %5 = insertelement <4 x i32> %3, i32 %4, i32 2 25 %6 = extractelement <4 x i32> %arg1, i32 1 26 %7 = insertelement <4 x i32> %5, i32 %6, i32 3 27 ret <4 x i32> %7 28 } 29 30 Subzero should recognize these sequences and recombine them into 31 shuffle operations where appropriate. 32 33* Add support for vector constants in the backend. The current code 34 materializes the vector constants it needs (eg. for performing icmp on 35 unsigned operands) using register operations, but this should be changed to 36 loading them from a constant pool if the register initialization is too 37 complicated (such as in TargetX8632::makeVectorOfHighOrderBits()). 38 39* [x86 specific] llvm-mc does not allow lea to take a mem128 memory operand 40 when assembling x86-32 code. The current InstX8632Lea::emit() code uses 41 Variable::asType() to convert any mem128 Variables into a compatible memory 42 operand type. However, the emit code does not do any conversions of 43 OperandX8632Mem, so if an OperandX8632Mem is passed to lea as mem128 the 44 resulting code will not assemble. One way to fix this is by implementing 45 OperandX8632Mem::asType(). 46 47* [x86 specific] Lower shl with <4 x i32> using some clever float conversion: 48http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100726/105087.html 49 50* [x86 specific] Add support for using aligned mov operations (movaps). This 51 will require passing alignment information to loads and stores. 52 53x86 SIMD Diversification 54======================== 55 56* Vector "bitwise" operations have several variant instructions: the AND 57 operation can be implemented with pand, andpd, or andps. This pattern also 58 holds for ANDN, OR, and XOR. 59 60* Vector "mov" instructions can be diversified (eg. movdqu instead of movups) 61 at the cost of a possible performance penalty. 62 63* Scalar FP arithmetic can be diversified by performing the operations with the 64 vector version of the instructions. 65