This is the mail archive of the
mailing list for the GCC project.
Re: Higher level RTL issues
- To: law at redhat dot com
- Subject: Re: Higher level RTL issues
- From: Diego Novillo <dnovillo at redhat dot com>
- Date: Tue, 9 Oct 2001 23:53:48 -0400
- Cc: gcc at gcc dot gnu dot org
- Organization: Red Hat Canada
- References: <email@example.com>
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.