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

[Dale Johannesen <dalej at apple dot com>]

On Tuesday, July 15, 2003, at 03:51  PM, Jim Wilson wrote:
> 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.

The loop.c patch.  I did say "from that point of view"; I understood 
that the
loop.c patch wasn't intended to fix the aliasing problem, but I don't 
think
everybody did.  I agree with your characterization (except for 
'obvious' :)
and I'm glad you're looking at this; you've explained why David Miller's
patch made the problem show up, which nobody else had.

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

It is not necessarily true that fixing the bug will introduce 
performance regressions.
If it is the case that the buggy code is moving some memory references 
out of
loops in cases where the compiler cannot tell that it is safe, and is 
getting lucky,
then yes, fixing the bug will cause regressions.  But I don't think we 
have
evidence of that.  (In practice, I mean - certainly that can happen in 
theory.)

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

That's the one I'm talking about.