On Thu, May 7, 2015 at 6:24 PM, Richard Henderson <r...@redhat.com> wrote: > On 04/24/2015 06:32 PM, Jan Hubicka wrote: >> Also I believe it was kind of Richard's design deicsion to avoid use of >> (paradoxical) subregs for vector conversions because these have funny >> implications. > > Yes indeed. > >> The code for handling upper parts of paradoxical subregs is controlled by >> macros around SUBREG_PROMOTED_VAR_P but I do not think it will handle >> V1DI->V2DI conversions fluently without some middle-end hacking. (it will >> probably try to produce zero extensions) >> >> When we are on SSE instructions, it would be great to finally teach >> copy_by_pieces/store_by_pieces to use vector instructions (these are more >> compact and either equaly fast or faster on some CPUs). I hope to get into >> this, but it would be great if someone beat me. > > Well, I think it would be worthwhile to teach the i386 backend how to do > 64-bit > vectors in SSE registers. First, this would aid portability with other > targets > who may have GCC generic vectors written only for 8 byte quantities. Since we > do have zero-extending 8 byte load/store insns for SSE, we don't actually need > paradoxical regs, just additional macro-ization of the existing patterns.
If we consider SSE operations as DImode operations, we will loose the ability to precisely specify which operation (SSE vs. general reg) we want. I'm afraid that in DImode case, combine will choose FLAG-less pattern that will mandate moves from general regs to SSE regs and back. This was the reason to invent V1DImode/V1TImode "vectors" to avoid moving double-mode values to MMX/SSE regs for double-mode shifts. The alternative would be RA that is able to select between alternative instructions, not only between alternative register classes. Uros.
