Re: bounded pointers in RTL

[Jeffrey A Law <law at cygnus dot com>]

  In message <199910132349.NAA05492@tucson-net-82.eng.ascend.com>you write:
  > These allowed BPs to travel through RTL land and be passed to
  > functions and returned from functions in registers with relative ease.
Right.

  > I have been considering the possibility of reimplementing BPs without
  > use of new modes, but it looks painful.  There are many places where
  > only the machine mode communicates the size of a data object.
Yup.  But it is also the case that every pass of the compiler is probably
going to have to know something about the new modes.  Similarly for all
the backends that define FUNCTION_ARG.

An alternative would be to use the complex types, but I really don't like
that since the complex types imply certain semantics when performing
arithmetic.


  > Without going into too much detail yet, I'm seeking some "spiritual
  > advice" on this subject.  Are bounded-pointer modes acceptable, or is
  > there a greater salvation in going "modeless" for which I should
  > accept the pain and suffering to adapt the RTL layer?
What specifically where you considering as an alternative?

  > The BP rtx will be a 3-field RECORD_REGS (I posted a patch a couple
  > weeks ago that replaced CONCAT with the general RECORD_REGS).  The
  > reason to go modeless would be to pave the way for user-defined
  > aggregates at the RTL layer.  In the past there has been some
  > discussion about the desirability of treating structs/classes as
  > collections if values independently assignable to registers, but
  > nothing about the implementation details.  Has anyone thought much
  > about this?
We do want to rethink the way structs are represented.  I'm not sure if
Michael was going to try and attack any of that with the work he's doing
now or not.  But the basic idea is to ultimately be able to assign structs to
regs.

The other approach is to have a global load/store optimizer, which will
(in effect) promote structure accesses to regs for maximal lifetimes within
the limits of alias analysis.  However, that works at a very low level and
due to the aliasing concerns it may not be powerful enough.

It may be the case that a combination of a change in the high level
representation of structures and a low level memory reference optimizer
is the way to go.  Not sure.

I did a global load optimizer for Cygnus a while ago (within gcse).  I'm
currently trying to decide whether or not to contribute it as-is or wait.
The fundamental issue is gcse/lcm does block insertions rather than edge
insertions.  As a result it is possible to get an expression evaluation on
a path where it did not previous have an evaluation, which can cause problems
with loads.

Right now my gut is telling me to wait -- Andrew MacLeod has an edge based
gcse/lcm implementation up and running which solves this problem.  I'm working
with Andrew to clean up the remaining loose ends so that it can be contributed
to GCC in the very near future.

jeff