Re: Higher level RTL issues

[law at redhat dot com]

  In message <20011009235348.A2183@tornado.cygnus.com>you write:
  > On Tue, 09 Oct 2001, Jeff Law wrote:
  > 
  > > I don't think there's any significant disagreement that a higher level
  > > IL would be useful.  What is a subject of debate is whether we have
  > > a lower tree form, higher RTL form or some other form.  I think if we
  > >
  > Or both.
Right.  Sorry if I wasn't explicit about my belief that there is a set of
problems that are best solved by Diego's approach and some that are best
solved by my approach.  Furthermore, I believe that Diego's code and my
code can peacefully co-exist in the compiler together.


  > We can still lower the tree representation without actually creating a
  > new IL.  This lowering would preserve full symbolic and array information
  > while simplifying the expression trees to remove most of the language
  > semantics (side-effects, sequence points, etc).
Right.  In fact one of the things I want to do (and touched upon briefly in
a previous message) is un-nesting of calls at the tree level and one day
have a more gradual lowering of memory addresses (the way we drop from,
ARRAY_REF, COMPONENT_REF, etc down to target specific addressing modes in 
tree->rtl translation right now is incredibly silly).  Similarly for how 
we handle any kind of partial-word/bitfield arithmetic (you pretend they
are full-word then lower to partial-word/bitfields later, my guess is at
least part of this will be best handled at the tree level).


  > I'm thinking of trees that ressemble three-address ILs.  They
  > would look just like trees to the tree-to-RTL pass and more
  > importantly they would provide a high-level IL that is more
  > language-independent than the current trees.  
Right.

  > > with any optimization which potentially has two SSA names for the same 
  > > variable live at the same point in the program.  GVN and dominator based
  > > value numbering can create situations where we have two SSA names live at
  > > the same time.  
  > >
  > Sorry, you missed me here.  Would you have an example? 
Yes.  Do you recall our phone conversation about the inner loop of compress
from several months ago?  When you apply value numbering (either GVN or 
dominator optimizations ala Morgan) on that loop in SSA form for the IA64 
port you'll find a redundant sign extension.

Removal of that sign extension causes two distinct SSA names for the same
original variable to be live at the same point and have different runtime
values.  Thus, we can not simply throw away the SSA names after removing
the useless sign extension.

I'll have to fire up my ia64 box and get you the RTL dumps which show what's
happening (it's supposed to get cold in SLC Sunday, so that might be a good
time to crank up the ia64 machine :-)

[ discussion of a whole new IL ... ]
  > Agreed, it needs to be an IL that we can evolve from an existing
  > one.  Either a lower-level tree representation as I outlined
  > above or a higher-level RTL, or both.  Each representation
  > supports orthogonal classes of transformations.  Anything closer
  > to the source is probably easier to do at some form of tree IL.
I think we're in violent agreement here :-)  I strongly feel that we'll
need both -- I just happen to have more of an interest in the RTL side
of things :-)


jeff