This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Contributing tree-ssa to mainline
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: dnovillo at redhat dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 19 Jan 04 09:19:30 EST
- Subject: Re: [RFC] Contributing tree-ssa to mainline
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.
VRP is one of the passes I'm planning to work on in the immediate
future. The goal is to eliminate mudflap checks, though it should
help Java and Ada as well.
Sure it will. There will indeed be checks that can't be supressed statically
that can with VRP, but the opposite is also true.
If the check needs dataflow information to be eliminated, the FE had
better not deal with it.
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. A check is merely a flag on an operation node in the
Ada tree. If it can be suppressed at that level, we avoid ever generating
*any* tree nodes for the check. That seems a good thing to me: why do you
see it as something that "had better not" happen?
Nothing in tree-ssa is language specific.
I didn't say there was. What I said was that it looked like the *example*
was relying on language-specific features. It turned out I misread the
message, but my concern was in the example only.
I have an idea. Why don't you provide test cases in the form of
bugzilla reports?
Because I don't exactly what the optimizations goals are, nor am I
particularly concerned about the details.
Even more, we could vote on a set of specific bugzilla PRs as merge or
post-merge criteria.
I think that would be unfair to the tree-ssa project. I don't see the merge
criteria as the GCC project giving some test cases to the tree-ssa folks and
saying "show me that you can improve these cases". I think that's much too
hard a standard to meet.
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.
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.