Re: How is generic SIMD support supposed to work?

[Jan Hubicka <jh at suse dot cz>]

> On Sun, Oct 20, 2002 at 02:46:28PM +0200, Jan Hubicka wrote:
> >   __v4si val = {1,2,3,4};
> >     return val;
> > }
> > and I hope this to be compiled into static initializer loaded at once.
> > Unforutnately this does not happen, but even worse compiler dies:
> 
> What happens on other architectures is that this value gets
> loaded into 4 integer registers, and the subregging works as

Yes, I know briefly how Sparc is working and I guess PPC has similar
architecture.  Too bad that XMM doesn't ;(

> expected.  That's going to be prohibitive on x86, so we either
> need to arrange for such pseudos to get allocated to the stack
> (via CLASS_CANNOT_CHANGE_MODE_P), and/or come up with another
> mechanism (via named patterns, I assume) for the code generator
> to ask to read or set a vector element.

Yes, named patterns is what I was thinking about, but the interface is
worrying me a bit.

We can define setM1M2 patterns pretty much in the style of Intel
intrincs.  However if you consider for instance moving from two MMX to
insgle SSE, you have to decide wehter to offload both to sequential
memory and read it or whether to do two MMX->SSE moves and shuffling.
This should be ideally decided on reload time but I don't see how it can
be accomplished.

For now I would be happy with CLASS_CANNOT_CHANGE_MODE_P sollution.
Unforutnately XMM registers can be subregged to SImode or DImode sanely
when the subreg is lowpart, but can't be done for non-lowpart subregs.
It may be usefull to do 64bit logical operations in SSE with movq used
for loading/storing operands, so CLASS_CANNOT_CHANGE_MODE_P does not
appear to do the job here for me too.

I will try to define it for a start to see what happends - at the moment
we don't use SI or DImode subregs on XMM.

Honza
> 
> 
> r~