[Bug rtl-optimization/44141] Redundant loads and stores generated for AMD bdver1 target

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44141

--- Comment #16 from Ulrich Weigand <uweigand at gcc dot gnu.org> 2012-05-07 17:17:06 UTC ---
Reload inheritance generally gives up on handling subregs of pseudos, mostly
because there is no mechanism to track invalidation of parts of pseudos.

Now, in this particular case where a subreg still refers to the whole of the
pseudo and just re-interprets it as a different vector mode, it might be
possible to enhance inheritance support to handle such cases.

But this looks like a significant chance to what is already one of the most
complex parts of reload -- and would certainly involve some risk of introducing
subtle bugs.   I'm not sure if this is worth the effort ...

In particular, in this specific case the back-end could make things a whole lot
simpler by not insisting on a particular mode.  I understand MOVUPS simply
moves 16 bytes between (unaligned) memory and registers -- there's nothing in
particular that requires this to be encoded as V4SF mode.

I'd suggest simply extending the movups patterns to handle moves between
arbitrary 16-byte (vector?) modes, all in the end resolving to the same
assembler instruction.  Then you'd be able to just encode the move in question
along the lines of
   (set (reg:V2DF) (unspec:V2DF [(mem:V2DF ...)] UNSPEC_MOVU))
which would probably generate better code not just in reload, but other parts
of the RTL middle-end as well ...

[ An even more radical change might be to encode both movups and movaps as just
plain moves, with no unspec, and have the final assembly output make the choice
between the two based on the operand's MEM_ALIGN value ... Of course, this
needs MEM_ALIGN to be always correct. ]