[patch] Lno branch merge part 3 -- ssa form updating improvements

[Diego Novillo]

On Wed, 2004-06-16 at 22:14, Zdenek Dvorak wrote:

> huhh?????? No you cannot do this.  Try thinking about say trace
> formation algorithm.  You will soon notice that updating the ssa form
> in this case indeed needs a fully generic algorithm that is able to
> handle arbitrary insertions.
> 
You are generalizing and making conclusions with no proof.  I took the
time of showing you an alternative that it was both efficient and easy
to implement.  At least help me understand your position.  You are
showing nothing of substance to support your claim.  What precisely
happens in trace formation?  Why is it impossible to implement it any
other way?

I clearly cannot show you prior art in this specific area in GCC, nor in
anything I have done.  It would be really interesting to find out what
the other big commercial compilers do in this area (IBM, Intel, SGI). 
None of those use the same SSA form that we use, though.  Still, if
anyone has contacts, it'd be great if we could find out.  Mostly what
has driven my position is the approach of trying to have small, specific
modules that do one thing well (this is what got me started with wanting
to take DOM appart a few months back).  Ken Zadeck also recommended
something similar in his keynote back in Ottawa.  There's also
literature that promotes incremental updates of the SSA form.


> And NOOOOO -- I really do not want to solve the same problem for each
> optimization separately.
>
We are not going to solve the same problem every time.  We will evolve
specific helpers to do changes deemed necessary by each transformation. 
Again the mental model is small specialized helpers doing a very
specific thing.  As opposed to the all-powerful passes that plague GCC.


> What I offer is a fully generic way usable at any place that needs
> code duplication/insertion, with well-defined semantics.
> 
It does not have well-defined semantics.  It will need to grow to handle
corner cases, it will replicate the SSA renamer, it has the potential of
having to take the program out of SSA form and back in.  There are too
many drawbacks from a maintenance point of view.

The other approach allows us to modify the program in a very controlled
manner and prevents us from doing exactly what you advocate: allow
passes to blindly perform arbitrary code motion.  If a pass needs to
move code around without understanding, then I claim that the pass has a
fundamental design flaw.

> Anyway, I withdraw from discussion with this mail; it becomes clear to
> me that the only way how to persuade you is to let you do this mistake
> and come up with this obvious solution in half a year again.
>
Dude, chill out.  We're talking bits and bytes here.  No need to get so
emotional about things.  We are only going to convince each other (or
agree to disagree) with a cool, rational discussion.


> My only problem is that this blocks merging of lno branch, so sorry to
> anyone who relied on it, but I cannot proceed with it just now.
>
Well, I showed you that the algorithm you were using this for is easily
replaceable with one that doesn't destroy the SSA form.  Again, we could
merge the branch and fix afterward.  I'm not so concerned with fixing
the problem today.  Just that we plan to fix it shortly after it's
merged in.

I wish you wouldn't get so upset, so easily.


Cheers.  Diego.