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]
Other format: [Raw text]

Re: [RFC] Contributing tree-ssa to mainline

On Mon, 2004-01-19 at 09:19, Richard Kenner wrote:
>     Full FE type information is available in GIMPLE.  
> The Ada tree has *a lot* more information than can be (or should be)
> encoded into the GCC tree datastructure.  Each tree node has 183 defined
> flags, for example.
OK.  When the time comes to generate GENERIC from Ada, then that
information should be propagated down.  One thing that I'm vaguely
concerned regarding Ada is the potential of having to create new GIMPLE
trees.  Having to create new GENERIC codes wouldn't be a problem, but
adding GIMPLE means changing the optimizers as well.  We'll see.

> I don't follow.  Why "had better not"?  For every check that the FE
> can eliminate, there's that much less work for the rest of the
> compiler to do.
I only meant checks that need dataflow information.  If the elimination
needs dataflow information, then the FE will be duplicating code and
effort.  If no dataflow info is needed, then by all means, remove away.

> Instead, I think the tree-ssa folks should implement several new
> optimizers that rely on higher-level information to show the utility of the
> new infrastucture and should produce test cases (preferably in C) that
> show the success of those optimizers.  I think that's both an easier and
> more relevant standard.
We have done several already.  Since you seem interested, please:

     1. Visit
     2. Get the branch or the daily binary snapshots and try it out.
     3. Read the source code.

>     What information?  Type?  Yes, we preserve full user-level type and
>     variable information.  Control flow?  We have a flow graph.  Data
>     flow?  We have an SSA web.  What specific information are you
>     concerned about?
> Information regarding the form of array and component accesses.  In a
> discussion about RTL loop code, I thought I saw that the addressing computation
> would be done early on and the COMPONENT_REFs and ARRAY_REFs would be removed.
No.  COMPONENT_REFs and ARRAY_REFs are kept (though we need to address
cases where the C FE is generating pointer dereferences instead of

There has been some discussion of perhaps lowering ARRAY_REFs.  But that
would be done relatively late in the tree pipeline.


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