This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Higher level RTL issues

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.  The tree form is still too high-level for some
transformations.  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).

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.  

> That model works fine for a class of optimization problems, but breaks down
> 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?  I agree
that we might find the FUD chains representation restricted for
some optimizations, but I'm not sure I follow this particular
case.  We can at least support most/all interesting loop
transformations with FUD chains.

> Now let's consider writing a new IL to sit between trees and RTL.  It can
> certainly be done, no doubt about that.  However, that means we have to
> come up with a new class of routines to analyze and manipulate this new IL
> as well as translators in/out of this new IL.  It means we as developers have
> to familiarize ourselves with a whole new IL.  It means that we can't use any
> of the existing work in the SSA translator and optimization passes.  In short
> I just don't think it makes a lot of sense.
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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]