Re: Patch ping ^ 2

[Daniel Berlin <dberlin@dberlin.org>]

On Oct 18, 2004, at 10:25 AM, Zdenek Dvorak wrote:

> Hello,
>
>>> 1) Unless your patch to make voperands represent output dependences 
>>> again
>>>    (http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01437.html) gets 
>>> into
>>>    mainline, the rewrite of store motion
>>>    (http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01120.html) is the 
>>> best
>>>    choice.
>>
>> 	Regardless whether Dan's patch gets approved for mainline, the
>> original, unmodified patch is taking GCC in the wrong direction and 
>> should
>> not be accepted.
>
> you cannot be serious.  Unless the msg01437.html patch is accepted, the
> rewrite is the only sane possibility how to solve PR 17133 (serious
> misscompilations...)
This is almost true.
The other option is to disable LIM for 4.0 until it's fixed, if the 
must-def patch doesn't go in.
However, you are correct that without that killing information, there 
would be no good way to fix 17133 in 4.0 besides disabling or your 
patch.


>
> And why do you assume that the direction in that the patch takes it is
> wrong?  It is the way at least one other compiler (LLVM) uses.

Not quite. At least, I don't believe it's quite the same.
LLVM will hoist loads/sink stores if the addressing arithmetic for a 
given load/store doesn't change.
It doesn't look like you do that anymore, but i can't quite tell.
IE they use the equivalent of single_reachable_address, called 
PointerInvalidatedByLoop for loads, and an is_loop_invariant check for 
stores, both of which it looks like you've removed (by removing 
single_reachable_address).

Also, LLVM does it this way because they *don't* have a virtual form 
for memory operands.

Open64 basically does what we were doing, except even more complex 
because it's part of SSAPRE on the reverse flowgraph (they nicknamed it 
SSUPRE, for single static use. They build an entirely new ssa form for 
stores), and SSAPRE is insanely complex.

IBM's compiler does it more or less like we do now (since they have 
virtual ssa form), only in ~500 lines of code. :)


>  It is
> clean and very easy to understand and extend.  Also once the
> msg01437.html is accepted (which it should, at least for 4.1, although 
> I
> think it is a bit too intrusive for 4.0), it is trivial to make it take
> advantage of SSA form for virtual operands.
>

I don't see how it would look much different from what we have now if 
you did.
I'd appreciate it if you could show me what you have in mind.


> Zdenek