<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 7, 2014 at 5:35 PM, Simon Pilgrim <span dir="ltr"><<a href="mailto:llvm-dev@redking.me.uk" target="_blank">llvm-dev@redking.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":330" class="a3s" style="overflow:hidden">Added X86vzmovl folded loads tests.<br>
<br>
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</div></blockquote><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>On x86, loads (especially of constants) are *crazy* fast in my experience.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":330" class="a3s" style="overflow:hidden"> 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.</div></blockquote><div><br></div><div>? If we want to fold things, it should happen before we're doing ISel pattern expansion... </div></div><br><br></div></div>