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. ]
