Patch ping ^ 2

[Daniel Berlin]

On Sun, 2004-10-17 at 23:43 +0200, Zdenek Dvorak wrote:
> Hello,
> 
> > > this patch fixes (at least) two several serious problems in lim store
> > > motion -- misscompilations (PR 17133 and several duplicates) and
> > > problems with compile time (PR 17790).
> > > 
> > > http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01120.html
> > 
> > I still have serious problems with this patch.
> > It simply drops using the SSA form to do store motion, and relies on
> > variable names and lack of aliasing to decide what to move.  
> 
> could you please explain more precisely what you mean by the last two
> points?  If "relies on variable names" means that it ignores ssa
> versions for virtual operands, yes, it does, since virtual operands are
> in FUD form,
>  so their ssa versions do not carry any interesting
> information
>  (if you do not use them to traverse UD chains, which does
> not make much sense in case you need to scan body of the whole loop
> anyway). 
This is only sort of true now (it's only true if you exclude must-defs,
and assume that our chains don't bypass non-aliasing uses, which they
admittedly happen to now), and certainly won't be true in the future.

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.

>  I have no idea what you mean by "relies on ... lack of
> aliasing".

The whole tag_ref counting thing.

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.
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.

"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.







> 
> Zdenek
--