subreg question

subreg question

[Dale Johannesen]

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?

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?

Re: subreg question

[Jan Hubicka]

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

Re: subreg question

[Aldy Hernandez]

>>>>> "Dale" == Dale Johannesen <dalej@apple.com> writes:

 > What cases of subreg are supposed to be handled exactly?
 > double x(float y) {
 >      double z;
 >      *((float *)&z) = y;     <-- boo!
 >      return z;  }

i believe this is invalid code, hence implementation dependent.  You
can't access an lvalue as a different type as it was declared.

Try unions.

 > 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?

 > The original case involved Altivec vectors, which as you recall are
 > 16 bytes:

 >      vector signed char v;
 >      int i;
 >      *((int *)&v) = i;

ditto here.  I don't think you can do this.-- well, should.

Aldy

Re: subreg question

[Dale Johannesen]

On Thursday, December 13, 2001, at 10:16 AM, Aldy Hernandez wrote:

>>>>>> "Dale" == Dale Johannesen <dalej@apple.com> writes:
>
>> What cases of subreg are supposed to be handled exactly?
>> double x(float y) {
>>      double z;
>>      *((float *)&z) = y;     <-- boo!
>>      return z;  }
>
> i believe this is invalid code, hence implementation dependent.  You
> can't access an lvalue as a different type as it was declared.

I don't see why not.  (C89) 3.3.4 says the cast might produce an invalid
pointer if it's not aligned properly, which is not the case here.
Other than that I don't find any relevant restriction in the standard.
What did you have in mind?
(FWIW, gcc doesn't warn about this even with -pedantic.)

> Try unions.

Unions don't create the subreg.

>> The original case involved Altivec vectors, which as you recall are
>> 16 bytes:
>
>>      vector signed char v;
>>      int i;
>>      *((int *)&v) = i;
>
> ditto here.  I don't think you can do this.-- well, should.

There is existing user code that does it.  Not that that should affect
what FSF gcc does necessarily, but I'm not convinced there's any reason
to bar this.

Re: subreg question

[Daniel Jacobowitz]

On Thu, Dec 13, 2001 at 12:21:33PM -0800, Dale Johannesen wrote:
> 
> On Thursday, December 13, 2001, at 10:16 AM, Aldy Hernandez wrote:
> 
> >>>>>>"Dale" == Dale Johannesen <dalej@apple.com> writes:
> >
> >>What cases of subreg are supposed to be handled exactly?
> >>double x(float y) {
> >>     double z;
> >>     *((float *)&z) = y;     <-- boo!
> >>     return z;  }
> >
> >i believe this is invalid code, hence implementation dependent.  You
> >can't access an lvalue as a different type as it was declared.
> 
> I don't see why not.  (C89) 3.3.4 says the cast might produce an invalid
> pointer if it's not aligned properly, which is not the case here.
> Other than that I don't find any relevant restriction in the standard.
> What did you have in mind?
> (FWIW, gcc doesn't warn about this even with -pedantic.)

It's not an invalid pointer.  It doesn't alias with Z, though.  That
assignment does not define Z, but only clobbers some memory.  You don't
get a warning because no one ever wrote the warning code for alias
violations; but this returns an undefined value, not y.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: subreg question

[Dale Johannesen]

On Thursday, December 13, 2001, at 12:28 PM, Daniel Jacobowitz wrote:

> On Thu, Dec 13, 2001 at 12:21:33PM -0800, Dale Johannesen wrote:
>>
>> On Thursday, December 13, 2001, at 10:16 AM, Aldy Hernandez wrote:
>>
>>>>>>>> "Dale" == Dale Johannesen <dalej@apple.com> writes:
>>>
>>>> What cases of subreg are supposed to be handled exactly?
>>>> double x(float y) {
>>>>     double z;
>>>>     *((float *)&z) = y;     <-- boo!
>>>>     return z;  }
>>>
>>> i believe this is invalid code, hence implementation dependent.  You
>>> can't access an lvalue as a different type as it was declared.
>>
>> I don't see why not.  (C89) 3.3.4 says the cast might produce an invalid
>> pointer if it's not aligned properly, which is not the case here.
>> Other than that I don't find any relevant restriction in the standard.
>> What did you have in mind?
>> (FWIW, gcc doesn't warn about this even with -pedantic.)
>
> It's not an invalid pointer.  It doesn't alias with Z, though.

Why not?

> That
> assignment does not define Z, but only clobbers some memory.

Seems to me it defines however much of Z is covered by a float-sized
object (4 out of 8 bytes, on most machines).  The other half of Z,
and its value, are indeed undefined.  If we had another assignment
to  *((float *)((char*)&z+4)), then all of Z would be defined (somehow).

> You don't
> get a warning because no one ever wrote the warning code for alias
> violations; but this returns an undefined value, not y.

Certainly.  I'm not suggesting this particular example does something
useful, just questioning the generated rtl.  Anyway, even an invalid
program doesn't justify generating invalid rtl.

Re: subreg question

[Daniel Jacobowitz]

On Thu, Dec 13, 2001 at 12:39:03PM -0800, Dale Johannesen wrote:
> 
> On Thursday, December 13, 2001, at 12:28 PM, Daniel Jacobowitz wrote:
> 
> >On Thu, Dec 13, 2001 at 12:21:33PM -0800, Dale Johannesen wrote:
> >>
> >>On Thursday, December 13, 2001, at 10:16 AM, Aldy Hernandez wrote:
> >>
> >>>>>>>>"Dale" == Dale Johannesen <dalej@apple.com> writes:
> >>>
> >>>>What cases of subreg are supposed to be handled exactly?
> >>>>double x(float y) {
> >>>>    double z;
> >>>>    *((float *)&z) = y;     <-- boo!
> >>>>    return z;  }
> >>>
> >>>i believe this is invalid code, hence implementation dependent.  You
> >>>can't access an lvalue as a different type as it was declared.
> >>
> >>I don't see why not.  (C89) 3.3.4 says the cast might produce an invalid
> >>pointer if it's not aligned properly, which is not the case here.
> >>Other than that I don't find any relevant restriction in the standard.
> >>What did you have in mind?
> >>(FWIW, gcc doesn't warn about this even with -pedantic.)
> >
> >It's not an invalid pointer.  It doesn't alias with Z, though.
> 
> Why not?

The C standard's aliasing rules.  *((float *)&z) is an object of type
float; double is a different type than float; z is an object of type
double; *((float *)&z) and z can not alias.

> >That
> >assignment does not define Z, but only clobbers some memory.
> 
> Seems to me it defines however much of Z is covered by a float-sized
> object (4 out of 8 bytes, on most machines).  The other half of Z,
> and its value, are indeed undefined.  If we had another assignment
> to  *((float *)((char*)&z+4)), then all of Z would be defined (somehow).

It sets that memory, but it doesn't define Z.  The fact that it clobbers Z
is somewhat incidental.

> >You don't
> >get a warning because no one ever wrote the warning code for alias
> >violations; but this returns an undefined value, not y.
> 
> Certainly.  I'm not suggesting this particular example does something
> useful, just questioning the generated rtl.  Anyway, even an invalid
> program doesn't justify generating invalid rtl.

Of course :)

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: subreg question

[Aldy Hernandez]

On Thu, 2001-12-13 at 12:43, Daniel Jacobowitz wrote:
> On Thu, Dec 13, 2001 at 12:39:03PM -0800, Dale Johannesen wrote:
> > 
> > On Thursday, December 13, 2001, at 12:28 PM, Daniel Jacobowitz wrote:
> > 
> > >On Thu, Dec 13, 2001 at 12:21:33PM -0800, Dale Johannesen wrote:
> > >>
> > >>On Thursday, December 13, 2001, at 10:16 AM, Aldy Hernandez wrote:
> > >>
> > >>>>>>>>"Dale" == Dale Johannesen <dalej@apple.com> writes:
> > >>>
> > >>>>What cases of subreg are supposed to be handled exactly?
> > >>>>double x(float y) {
> > >>>>    double z;
> > >>>>    *((float *)&z) = y;     <-- boo!
> > >>>>    return z;  }
> > >>>
> > >>>i believe this is invalid code, hence implementation dependent.  You
> > >>>can't access an lvalue as a different type as it was declared.
> > >>
> > >>I don't see why not.  (C89) 3.3.4 says the cast might produce an invalid
> > >>pointer if it's not aligned properly, which is not the case here.
> > >>Other than that I don't find any relevant restriction in the standard.
> > >>What did you have in mind?
> > >>(FWIW, gcc doesn't warn about this even with -pedantic.)
> > >
> > >It's not an invalid pointer.  It doesn't alias with Z, though.
> > 
> > Why not?
> 
> The C standard's aliasing rules.  *((float *)&z) is an object of type
> float; double is a different type than float; z is an object of type
> double; *((float *)&z) and z can not alias.

agreed.  be that as it may dale, if the compiler is crashing, it's a
bug, so it needs to be fixed :)

aldy

Re: subreg question

[Dale Johannesen]

On Thursday, December 13, 2001, at 12:43 PM, Daniel Jacobowitz wrote:
>>>>
>>>> I don't see why not.  (C89) 3.3.4 says the cast might produce an 
>>>> invalid
>>>> pointer if it's not aligned properly, which is not the case here.
>>>> Other than that I don't find any relevant restriction in the standard.
>>>> What did you have in mind?
>>>> (FWIW, gcc doesn't warn about this even with -pedantic.)
>>>
>>> It's not an invalid pointer.  It doesn't alias with Z, though.
>>
>> Why not?
>
> The C standard's aliasing rules.  *((float *)&z) is an object of type
> float; double is a different type than float; z is an object of type
> double; *((float *)&z) and z can not alias.

Can you point me to someplace in the standard that says this?

Re: subreg question

[Daniel Jacobowitz]

On Thu, Dec 13, 2001 at 01:04:01PM -0800, Dale Johannesen wrote:
> 
> On Thursday, December 13, 2001, at 12:43 PM, Daniel Jacobowitz wrote:
> >>>>
> >>>>I don't see why not.  (C89) 3.3.4 says the cast might produce an 
> >>>>invalid
> >>>>pointer if it's not aligned properly, which is not the case here.
> >>>>Other than that I don't find any relevant restriction in the standard.
> >>>>What did you have in mind?
> >>>>(FWIW, gcc doesn't warn about this even with -pedantic.)
> >>>
> >>>It's not an invalid pointer.  It doesn't alias with Z, though.
> >>
> >>Why not?
> >
> >The C standard's aliasing rules.  *((float *)&z) is an object of type
> >float; double is a different type than float; z is an object of type
> >double; *((float *)&z) and z can not alias.
> 
> Can you point me to someplace in the standard that says this?

Sorry, I don't have a copy.  It should be described along with the rest
of the aliasing rules, where that may be.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: subreg question

[Aldy Hernandez]

On Thu, 2001-12-13 at 13:04, Dale Johannesen wrote:
> 
> On Thursday, December 13, 2001, at 12:43 PM, Daniel Jacobowitz wrote:
> >>>>
> >>>> I don't see why not.  (C89) 3.3.4 says the cast might produce an 
> >>>> invalid
> >>>> pointer if it's not aligned properly, which is not the case here.
> >>>> Other than that I don't find any relevant restriction in the standard.
> >>>> What did you have in mind?
> >>>> (FWIW, gcc doesn't warn about this even with -pedantic.)
> >>>
> >>> It's not an invalid pointer.  It doesn't alias with Z, though.
> >>
> >> Why not?
> >
> > The C standard's aliasing rules.  *((float *)&z) is an object of type
> > float; double is a different type than float; z is an object of type
> > double; *((float *)&z) and z can not alias.
> 
> Can you point me to someplace in the standard that says this?

i am NOT a language lawyer, as most of my patches can show :))

but i think this is it:


    7 An object shall have its stored value accessed only by an lvalue
    expression that has one of the following types:73) [The intent of
    this list is to specify those circumstances in which an object may
    or may not be aliased.]   a type compatible with the effective type
    of the object,   a qualified version of a type compatible with the
    effective type of the object,   a type that is the signed or
    unsigned type corresponding to the effective type of the object,   a
    type that is the signed or unsigned type corresponding to a
    qualified version of the effective type of the object,   an
    aggregate or union type that includes one of the aforementioned
    types among its members (including, recursively, a member of a
    subaggregate or contained union), or   a character type.

Re: subreg question

[Richard Henderson]

On Thu, Dec 13, 2001 at 01:35:04PM -0800, Aldy Hernandez wrote:
> i am NOT a language lawyer, as most of my patches can show :))
> 
> but i think this is it:

Correct.  For the record, C99 section 6.5 paragraph 7.  Similar
language exists in C89, but I don't have the section number handy.


r~

Re: subreg question

[Joe Buck]

> > The C standard's aliasing rules.  *((float *)&z) is an object of type
> > float; double is a different type than float; z is an object of type
> > double; *((float *)&z) and z can not alias.
> 
> agreed.  be that as it may dale, if the compiler is crashing, it's a
> bug, so it needs to be fixed :)

Right.  The compiler must not crash for any input whatsoever, no matter
how nonstandard, otherwise it's a bug, and a rather severe one at that.
And this is the type of non-standardness that our users are likely to
feed to us, since the C aliasing rules are not widely known about even
by experienced C programmers.

Re: subreg question

[Paul Brook]

> How to tell gcc to insert high, low, and combine operations, when 32
> and 64 bit operations are exchanging values?

CANNOT_CHANGE_MODE_CLASS

Paul

subreg question

[Jan Hoogerbrugge]

Hi,

My target architecture has 32 bit registers and uses register pairs
for 64 bit values. What makes it special is that whenever a register
pair is written by a 64 bit operation, the individual registers should
not be read by 32 bit operations. The reverse is also true: whenever a
register pair is used as 64 bit operand, the value should not be
produced by 32 bit operations.

In order to connect 64 to 32 operations, the target architecture
provides high and low, which select a register from a register pair,
and combine, which combines two registers into a register pair.

How to tell gcc to insert high, low, and combine operations, when 32
and 64 bit operations are exchanging values?

Regards,
Jan