Patch ping ^ 2

[Daniel Berlin]

On Mon, 2004-10-18 at 01:43 +0200, Zdenek Dvorak wrote:
> Hello,

> > Consider:
> > 
> > 
> > a_3 = V_MAY_DEF <a_2, 0, 4>
> > a_4 = V_MAY_DEF <a_2, 4, 8>
> > 
> > If you only look at names, you will move neither store.
> 
> yes, once you start doing this type of changes you do on your branch
> that are completely incompatible with how the system currently works,
> the things will have to be changed.

And making the types of assumptions you are proposing building into LIM
make exactly these types of changes much harder.  Which is why i said if
we go down the route of applying your patch, I would just rewrite LIM.


> > >  I have no idea what you mean by "relies on ... lack of
> > > aliasing".
> > 
> > The whole tag_ref counting thing.
> 
> This just precisely reflects what information on aliasing is currently
> provided.
>   Assuming that your changes will be accepted, this will have
> to be changed (and of course, the ssa form based implementation would
> have to be changed as well)
Not really, the ssa form implementation would just work, unless you've
got some weird stuff hidden in there.
It does just work, actually, AFAIK.

> 
> > As for your earlier message that:
> > 
> > >1) It does not really bring any advantages over conventional
> > >approaches.
> > 
> > This is not true.
> > For example, you can do a neat form of promotion of entire blocks where
> > the conditional edge is when it is in ssa form that you simply can't do
> > easily without ssa form.
> 
> I cannot parse this sentence.
> 

s/conditional edge is/conditional test is invariant/

> > It would be true to state that your current implementation takes no
> > special advantage of SSA form, however, it is not true to state that
> > nobody does store motion better because it's done on SSA form.
> > 
> > "2) It is slower than conventional approaches."
> > Only if you make it so.
> > Considering the majority of other commercial compilers (IBM, Intel,
> > Open64) and aggressively optimizing non-commercial compilers (LLVM, for
> > example) do store motion on SSA, and do so very very quickly, this leads
> > me to believe that the problem is in your implementation, not with the
> > algorithm itself.
> 
> You are wrong at least about LLVM, for sure.

Uh, see LICM.cpp.

>   LLVM does not represent aliasing info in ssa form.  
I never said it did.
You said store motion was slower on SSA than convential approachs,
LLVM's is on ssa and it is not slower.


> I do not know much about other compilers,
> but I suspect gcc is the only one that does attempt to do it.
You'd suspect very wrong.
Open64 has mu and chi nodes to represent aliasing in ssa form, IBM's
compilers have even more types of ssa references for aliasing (they
actually have indirect-ssa uses that also have a pointer to all the ssa
defs that make up the addressing arithmetic for things like
indirect_refs).


> 
> > "3) It is more complicated and harder to understand than conventional
> >    approaches."
> > This is only because you are doing it in a somewhat ad-hoc way.
> > Store motion, is not hard to understand or more complicated in SSA form
> > that it is elsewhere. You have exactly the same legality conditions,
> > it's actually easier to test them.
> 
> I thought that as well, before I tried to implement it.

Did you ever ask for help when you ran into trouble?
I'm sure people would have been more than happy to try to explain how do
to it fast in SSA form.

> 
> Zdenek
--