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:31, Mark Mitchell wrote:
> I thought that Jim's patch might have already fixed this kind of
> issue.   The problem here is that the aliasing code thinks that because
> there is a different "base register" for the two MEMs there must be no
> conflict.

There are multiple problems and patches here.

My first patch was an alias.c patch which I think is conservatively
correct.  David Edelsohn objected to the performance regressions caused
by it, but did not provide any specifics.  This patch is in limbo until
I have more time to work on this problem.

My second patch was a loop.c patch which fixed an obvious bug introduced
by David Miller's patch which changed how instruction sequences work. 
This fixed one of the 3 bugs (9745), but not the other two (10021 and
11319).  This did not address the underlying problem with the alias info
being wrong.

I put a lot of info about the bug into this message:
	http://gcc.gnu.org/ml/gcc/2003-07/msg00668.html

At the moment, I am trying to do 4 broad things, help rms, help answer
questions on the gcc list, help review patches on the gcc-patches list,
and help fix bugs for 3.3.1.  This makes it difficult to accomplish much
on any one of these tasks, but I am certainly willing to adjust
priorities if necessary.

> The short-term fix is to treat the frame pointer as "may point at
> anything".  David Edelsohn has made the claim that this will reduce
> performance.  This bug, however, is so prevalent that I fear we have
> little choice but to take the hit.

This is apparently based on David's early analysis of PR 9745.  I
haven't looked into this.  I started with PR 10021, and the frame
pointer has nothing to do with the alias problem there.  Also, I don't
believe this has anything to do with PR 11319.  And PR 9745 was already
fixed by my "obvious" loop.c patch, so it isn't clear if this is still
relevant.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com