[Bug rtl-optimization/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609

--- Comment #26 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Henderson from comment #22)
> (In reply to Jeffrey A. Law from comment #21)
> > So going back to the original problem, for a subreg of a multi-word reg, 
> > why can't we simplify that down to a suitably sized reg?
> 
> Because we're dealing with registers of different sizes.
> 
> Assigning to a subreg as the low-part of a multi-word pseudo only
> makes sense when talking about general registers, which is the only
> place that "word_mode" applies.

Hmm, I don't see this documented anywhere.  In fact there is no such
thing as a "vector register", there are only vector modes.  And we
are using %xmm for plain SF/DFmode all over the place.

Note that in the particular case the mode we subreg is TImode,
not a vector mode.

> When talking about vector registers, which are universally larger
> than word-mode, we cannot simply assign to a subreg.
> 
> There is a vec_set named pattern that can perform an insertion into
> a vector element, like what's being demonstrated in the test source
> here.  Ideally that's how we'd have expanded this originally.

Indeed, if expand can see we are setting the low part of a vector
then it should try using vec_set.  Auditing of other targets might
be necessary here though.  And of course the i386 backend might
end up choosing movdf for this operation anyway...

> We already have ix86_cannot_change_mode_class to avoid the cases
> that we knew we couldn't support, e.g. QI and HImode loads/stores.
> But perhaps we should prevent all size-changing mode changes for
> the vector registers.

That may be a workaround for x86 but I don't see how this fixes the
issue in general given that targets may have general registers larger
than word_mode (is x32 TARGET_64BIT?).