[llvm-commits] [llvm] r142152 - in /llvm/trunk: lib/CodeGen/SelectionDAG/ test/CodeGen/ARM/ test/CodeGen/CellSPU/ test/CodeGen/X86/

[Owen Anderson]

Nadav,

On Oct 17, 2011, at 1:37 PM, Rotem, Nadav wrote: 
> The new type-legalization generates new code sequences. For example: trunc store and anyext loads.  I implemented fast load/store sequences  for x86.  Other targets also need to optimize the new sequences.  I opened a bug report on this PR11158.

Unfortunately, that PR does not cover the issue exposed in the testcase I pointed out, which is a real, significant performance issue with this approach.  Take a look at this snippet:

define void @test_vrev64(<4 x i16>* nocapture %source, <2 x i16>* nocapture %dst) nounwind ssp {
entry:
  %0 = bitcast <4 x i16>* %source to <8 x i16>*
  %tmp2 = load <8 x i16>* %0, align 4
  %tmp3 = extractelement <8 x i16> %tmp2, i32 6
  %tmp5 = insertelement <2 x i16> undef, i16 %tmp3, i32 0
  %tmp9 = extractelement <8 x i16> %tmp2, i32 5
  %tmp11 = insertelement <2 x i16> %tmp5, i16 %tmp9, i32 1
  store <2 x i16> %tmp11, <2 x i16>* %dst, align 4
  ret void
}

In NEON, vectors of i16 are legal, but i16 is not.  The correct code generation sequence was to collapse all of the insert/extract vectors into a shuffle, at which point there are longer illegal types present.  With your change, we promote all the vectors to vector of i32, at which point we can no longer match the desired shuffle instruction, in addition to having to emit a (possibly inefficient) vector trunc_store.  Even if we do add an efficient trunc_store lowering to ARM backend, it will still be unable to match the efficient shuffle because we have obfuscated the code by promoting rather than collapsing it to a shuffle.

That collapse to a shuffle is what the test that removed was checking for.

--Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20111017/61a5061c/attachment.html>