Re: SUBREGs

Re: SUBREGs

[Jeffrey A Law]

Note I've moved this to egcs@cygnus.com.

  In message <199809150945.KAA03265@phal.cygnus.co.uk>you write:
  > > The fix is to change the representation.  I've decided that the
  > > cleanest thing to do is to change SUBREG_WORD() to SUBREG_BIT().  Then
  > > perhaps one more macro defined by the target macros which tells
  > > the correspondance between hard regno and bit sizes.
  > ...
  > > Nevertheless I would like to hear some feedback from others
  > 
  > Using bits as the basic unit can lead to problems if you want to describe
  > a member of a struct that is larger than 1/8th of the address space.
  > It would be safer to use addressable units (for most targets, that's bytes).
  > 
  > Even then, we have to be aware that only an unsigned quantity can
  > be relied on to describe the size of an object that is larger than
  > one half of the address space.
I don't think we have to worry about such large values being held in
a SUBREG/REG.  Seriously, do we really forsee a REG/SUBREG with a
size that approaches 1/8 of the address space for the target?  That's
a little absurd.

jeff

Re: SUBREGs

[Jeffrey A Law]

  In message < 199809160545.WAA18568@dm.cobaltmicro.com >you write:
  >    I don't think we have to worry about such large values being held in
  >    a SUBREG/REG.  Seriously, do we really forsee a REG/SUBREG with a
  >    size that approaches 1/8 of the address space for the target?  That's
  >    a little absurd.
  > 
  > I think the original problem is that you could see a BLKmode SUBREG.
!?!  That's shouldn't be happening since there's no size associated
with BLKmode.

  > Or similarly, what about paradoxical and MEM subregging?
I don't see how either of these cause problems.

(subreg:BIGMODE (reg: SI) 0)

Should work just as before if you specify the size of the subreg.

jeff

Re: SUBREGs

[David S. Miller]

   Date: Tue, 15 Sep 1998 10:19:45 -0600
   From: Jeffrey A Law <law@cygnus.com>

     In message <199809150945.KAA03265@phal.cygnus.co.uk>you write:
     > Even then, we have to be aware that only an unsigned quantity can
     > be relied on to describe the size of an object that is larger than
     > one half of the address space.

   I don't think we have to worry about such large values being held in
   a SUBREG/REG.  Seriously, do we really forsee a REG/SUBREG with a
   size that approaches 1/8 of the address space for the target?  That's
   a little absurd.

I think the original problem is that you could see a BLKmode SUBREG.

Or similarly, what about paradoxical and MEM subregging?

As an amusing side note, Richard and myself have pondered removing
SUBREGs entirely, and starting from scratch with a new RTL code named
CHMOD :-)

Later,
David S. Miller
davem@dm.cobaltmicro.com

subregs

[Kenneth Zadeck]

This is a reply to jeff's mail about subreg's in 

http://gcc.gnu.org/ml/gcc/2004-04/msg01278.html

what is desirable is depends on where you are during a compilation.

It is desirable to have the front end of the compiler generate each
load and store as a seperate sequence, i.e. not combine them.  The
motivation here is the same one where gcc currently treats the fields
of small structures as separate variables: each of the small
operations more likely to be optimized by the commoning and code
motion algorithms than if they are left as aggragates.

> (sequence [
>   (insn (set (reg X_1) (reg X_0)))
>   (insn (set (subreg (reg X_1)) Y))
> ])


However, it is also quite desirable to combine the loads and stores
back into aggragates (the jeff extension) as a optimization to be
performed very late, (ideally after some preliminary scheduling)
because you really can do a much better job with the low level code
generation if you can glom together the masking and shifting
operations for several loads and stores.  This can be done with a
simple hack to any full redundancy elimination algorithm.

> This SEQUENCE, considered as a whole, is in SSA form.  It has an
> input, X_0, and an output, X_1.  X_1 will be set only by this insn.
> 
> As an extension, it's nice to recognize cases like
> 
> (insn (clobber (reg X)))
> (insn (set (subreg (reg X) 0) Y))
> (insn (set (subreg (reg X) 1) Z))
> 
> which together set all of X, and turn them into
> 
> (sequence [
>   (insn (clobber (reg X_1)))
>   (insn (set (subreg (reg X_1) 0) Y))
>   (insn (set (subreg (reg X_1) 1) Z))
> ])
> 
> to eliminate the dependency on the previous value of X; and it's also
> nice to eliminate unnecessary copies when converting out of SSA form
> (I think this is just an extension of the usual unnecessary copy
> elimination).
>