[lno] Avoid use of rewrite_ssa_into_ssa in loop header copying

Daniel Berlin dberlin@dberlin.org
Sun Jul 18 18:00:00 GMT 2004


On Jul 17, 2004, at 9:38 PM, Zdenek Dvorak wrote:

> Hello,
>
>>> I almost think this is a bug in your code rather than PRE.
>>
>> 	This is a bug in Zdenek's code.
>
> an you know that how?
Because your change shouldn't change anything.
But regardless, it could be a bug in GVN-PRE.
Have you compared code before and after to see where "PRE is breaking"?
Can you provide me a small testcase?
Have you tried it on mainline with a similar code change?
There hasn't been a PRE merge in quite a while, since before the VN 
changes, so it's possible it's a bug that has already been fixed.

>
>> Zdenek, please do not commit your patch to the LNO branch.
>
> I already did.  If someone says me where the bug is, I will be happy to
> fix it (and since the patch does not cause any problems except with
> PRE which nobody on works on on LNO branch, I am not going to revert
> it).
>

This of course, doesn't mean anything at all.
Most "bugs in PRE" tend to be bugs elsewhere.
At least, that is what history has shown.
Not that GVN-PRE doesn't have bugs, it's just they are a well-defined 
set of failures.
For example, the most "common" symptom is an ICE in 
find_or_generate_expression.
This almost always means something has been marked as anticipated that 
isn't actually available where we think it is anticipated.  This is 
either due to incorrect value numbering, or incorrect ssa given to PRE 
(the actual phi translation and anticipability computation is rather 
easy to prove correct, so bugs generally don't turn up there).
The value numbering is rather stable now too.

However, regardless of all of this, the fact remains that merging this 
problem into the lno branch means that we can't rely on lno branch 
testing before submitting things to the mainline, since they won't 
include testing with PRE, which is enabled on the mainline!

This is a very bad idea to do when we are in the middle of trying to 
merge patches from that branch.

> Zdenek



More information about the Gcc-patches mailing list