Re: subreg question

[Jan Hubicka <jh at suse dot cz>]

> What cases of subreg are supposed to be handled exactly?
> 
> double x(float y) {
>     double z;
>     *((float *)&z) = y;
>     return z;  }
> 
> On ppc, the rtl for the store after purge_addressof looks like:
> 
> (insn 36 12 17 (set (subreg:SF (reg/v:DF 118) 0)
>         (reg:SF 121)) -1 (nil)
>     (nil))
> 
> This seems to work (118 eventually gets resolved to memory) despite
> an explicit statement in rtl.texi that it is invalid.  Is it really?

It always has been considered invalid by documentation and major developers
(I've heart that first from Jeff).
But since it has been generated on the testcase above for a while, most
of code handle it properly, but suboptimally in many cases.

Major problem is handling of the registers.  Some architectures support
such subreg dirrectly (for instance the SSE on i386), but others can't
do that w/o storing to memory (for instance x87 on i386 that do have
all registers extended to 80bits), and gcc has no information about
that, so it always seems to resolve it using memory, so it is probably
better to avoid the generation of such code and explicitly offload it.

Thats all I know.  I am not sure if this is satisfying answer
to your question :)
> 
> The original case involved Altivec vectors, which as you recall are
> 16 bytes:
> 
>     vector signed char v;
>     int i;
>     *((int *)&v) = i;
> 
> This similarly produces
> 
> (insn 217 40 43 (set (subreg:SI (reg/v:V16QI 126) 0)
>         (reg/v:SI 115)) 310 {*movsi_internal1} (insn_list 4 (nil))
> 
> which is currently not handled.  There is no way to generate code for
> this except by putting 126 in memory.  The subreg use here does not
> seem to correspond to any of the uses described in rtl.texi, so it
> seems to me it should not be generated by purge_addressof.  Is this
> a reasonable approach?
Well, this setting appears to have better defined meaning than
in floating point case.  The vector modes are much like integers.
I am not sure if using special RTX code for accessing portions of
vector modes instead of reusing subreg has been good decision, even
when I see that subreg is nasty thing...

But this definitly needs to be re-tought.

Honza
> 
> 
>