Re: PR 11319 analyzed (Re: Patch fixing 3.3 bug PR 9745 and PR10021)

[Jim Wilson <wilson at tuliptree dot org>]

On Tue, 2003-07-15 at 13:58, Dale Johannesen wrote:
> My patch does not fix the real problem in the aliasing code, but 
> neither does
> Jim's patch, as Franz has demonstrated; from that point of view they're 
> equally
> hackish.

This seems confused.  Which one of my patches are you talking about? 
The alias.c patch or the loop.c patch?  It is already known that the
loop.c patch does not fix 11319 and 10021.  Franz never said anything
about my alias.c patch, so he could not have demonstrated that it didn't
fix anything.  Also, I don't see how either of my patches could be
described as hackish.  My loop.c patch fixes an obvious regression
introduced by an earlier patch from David Miller.  My alias.c patch
fixes the code to work as documented.

There was also a emit-rtl.c patch from me, but I am pretty sure that you
aren't talking about that one.

>  Mine does fix more of the known occurrences of the bug and 
> does
> not introduce a performance regression; there are grounds for 
> considering it
> superior, IMO.

I haven't seen any evidence that shows that my alias.c patch does not
work in cases where your patch does work.  My loop.c patch does not work
in cases where yours does, but my loop.c patch was never meant as a
complete solution for the aliasing problem.

Also, this talk about performance regressions is misleading.  The bug
here is that loop is performing unsafe optimizations due to incorrect
alias analysis.  If we fix that bug, then obviously we are going to have
performance regressions.  This is unavoidable because of the nature of
the bug.  Thus both my alias and loop patches cause performance
regressions.  Your patch causes less performance regression because it
doesn't fix the underlying bug, it just works around it in some cases. 
On the plus side, I have explained how to fix the loop optimizer to get
back the performance lost by the alias fixes.

> I did run into a case where my patch doesn't work and Jim's does. 
> ...
> (I stopped when I did because Jim's 
> patch
> came by so I tried that instead.)  Or we could apply both patches.

I am not sure which one of my patches you are referring to here.  My
loop.c patch is already on the gcc-3.3 branch.

> We tried Jim's patch (in combination with mine, but that shouldn't 
> matter)
> on SPEC on ppc Darwin and did not get a performance regression.  Are
> you sure the regression on x86 is due to this patch?

Which one of my patches did you try?

I didn't see anyone mention an x86 performance regression in this
thread.

Roger Sayle's mentioned an x86 regression in a different thread, that
appears to be due to my loop.c patch.  I don't think anyone has proven
it yet, but it is likely to be my patch.  This was a 3-4% performance
loss on x86 SPECfp.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com