[PATCH] [X86][SSE] Keep 4i32 vector insertions in integer domain on pre-SSE4.1 targets

[Simon Pilgrim]

On 7 Dec 2014, at 16:50, Chandler Carruth <chandlerc at gmail.com> wrote:
> On Sun, Dec 7, 2014 at 5:35 PM, Simon Pilgrim <llvm-dev at redking.me.uk> wrote:
> Added X86vzmovl folded loads tests.
> 
> I looked at using a pand with a constant mask as an alternative and saw a minimal regression (nearly in the noise) compared to the movq/movss versions I was already testing against. I'm worried about pursuing that route though - it adds addiitonal memory access
> 
> I would be *really* surprised if pand is actually slower, especially if we get a chance to hoist the memory access into a variable within a loop.
> 
> pand should be 2 uops, and according to agner's has a throughput of 2/cycle. the pshufd alone is 1 uop and 2/cycle. the movq is also 1 uop with 2/cycle. But because they're in a chain, the critical path is 2 cycles instead of 1 cycle here (assuming the load doesn't stall, but I think that's usually a safe assumption in real world code).
> 
> On x86, loads (especially of constants) are *crazy* fast in my experience.

Yes if I hoist the mask loading its definitely faster - but if I leave it folded in the pand I don’t see any difference.

> and the mask approach might make it more difficult for future optimizations of the multiple pshufd ops that are still in the vector-shuffle-128-v4.ll tests.
> 
> ? If we want to fold things, it should happen before we're doing ISel pattern expansion… 

Yes you’re right - its just that last shuffle/byteshift in lowerVectorShuffleAsElementInsertion isn’t doing us any favours as we’re making no attempt to fold it with the VZEXT_MOVL that we’ve just generated. I could just modify lowerVectorShuffleAsElementInsertion to try and have it create something more suitable - overriding most of the patterns (doing much of the VZEXT_MOVL work in code). Any better ideas? I wasn’t intending to spend so long on this pre-SSE4.1 code…….


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