Re: [RFC] Contributing tree-ssa to mainline

[Diego Novillo <dnovillo at redhat dot com>]

On Mon, 2004-01-19 at 07:26, Richard Kenner wrote:

> A case I know about in Ada is check elimination.  Because the default for Ada
> is enabling checking, it's quite important to eliminate checks that can be
> proven not to fail.  Theoretically, a lot this could be language-independent
> optimizers by value range propagation and related optimizations.  But the
> front-end can do a much better job because it has information only it knows.
>
Such as?  Full FE type information is available in GIMPLE.  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.

> Moreover, by suppressing the check before generating any code for it,
> compilation time is reduced.  I think this is clearly the proper place for
> that optimization.
> 
If the check needs dataflow information to be eliminated, the FE had
better not deal with it.


> That's why I asked about this, if it's truly C++-specific: wouldn't it be
> better in the C++ front end?  That's why it's important to understand how
> language-independent it is.
> 
Nothing in tree-ssa is language specific.  There's quite a bit of design
documentation available in the project's page.  The presentations last
year at GCC Summit should be useful.  And you can always check the
branch out and check for yourself.


> However, I'm not as willing as some people to simply accept the argument that
> this will lead to "considerable benefits" due to what are essentially
> theoretical arguments.  I'm a pragmatist: I'd like to *see* those benefits.
> 
I have an idea.  Why don't you provide test cases in the form of
bugzilla reports?  We have some reports that point out specific
performance problems that we have been addressing all along.  Merge or
no merge, those test cases will help fix the more noticeable problems. 
Particularly if they are representative samples of popular constructs.

Even more, we could vote on a set of specific bugzilla PRs as merge or
post-merge criteria.  I am going to be creating some PRs for the
specific issues that were raised in the thread regarding documentation,
for instance.


> One specific concern I have is the issue of when to lower.  I admit I haven't
> been following the project closely, so please feel free to correct me if I'm
> wrong, but my sense is that lowering of the level of the tree is now being
> done very *early*.  That seems to me to be potentially incompatible with the
> argument that doing such things as loop optimization at the tree level can
> use higher-level information: are we preserving such information?
> 
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?

> As I said, perhaps I misunderstand what's going on, but if I don't, I think
> the above is the critical issue and the design space of when to lower needs
> to be resolved by actually demonstrating some of the hoped-for high-level
> optimizations. I would not be comfortable merging tree-ssa until that level
> of design issues have been settled.
>
I really think you ought to take a look at the branch before we can
address your concerns.  You are being woefully vague.


Diego.