[PATCH] D49280: [X86] Remove isel patterns for MOVSS/MOVSD ISD opcodes with integer types.

[Simon Pilgrim via Phabricator via llvm-commits]

RKSimon added a comment.

In https://reviews.llvm.org/D49280#1163872, @greened wrote:

> In https://reviews.llvm.org/D49280#1163648, @RKSimon wrote:
>
> > In https://reviews.llvm.org/D49280#1162909, @craig.topper wrote:
> >
> > > Which microarchitecture cares about switching PD/PS? To my knowledge, no Intel architecture cares. Do any of the AMD architectures care?
> >
> >
> > It tends to be only the 'weird mixture' PS/PD domain shifts that cause a stall: VADDPS then VMULPD, that kind of thing - shuffles and bitops tend to be more forgiving (and more easy to fix.)
>
>
> The AMD 17h Optimization Guide has this to say:
>
> "Try to use consistent data types for instructions operating on the same data. For example, use 
>  VANDPS, VMAXPS, and so on when consuming the output of MULPS."
>
> The inclusion of VANDPS in that list makes me think all such domain crossings may incur a penalty.
>  I have not seen an explicit list anywhere of what is and is not bad.  A VADDPD feeding a VANDPS
>  is probably not a programming error but it would incur a penalty.


We do our hardest to keep to the same domain already - like I said on PR38157 bitops and (some) unpacks/shuffles are already handled but we can always do more (patches welcome!).



================
Comment at: test/CodeGen/X86/oddshuffles.ll:1332
+; SSE2-NEXT:    movups %xmm7, 16(%rcx)
+; SSE2-NEXT:    movups %xmm1, (%rcx)
 ; SSE2-NEXT:    retq
----------------
TBH, this would be better if we stayed purely in the float domain.


Repository:
  rL LLVM

https://reviews.llvm.org/D49280