This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Tue, 2003-07-15 at 12:52, Franz Sirl wrote:
> On Friday 11 July 2003 08:55, Jim Wilson wrote:
> > On Thu, 2003-07-10 at 09:18, Mark Mitchell wrote:
> > > I concur -- Jim, please apply the patch and close those PRs which are
> > > indeed fixed.
> >
> > I've added the patch to mainline and the 3.3 branch.
> >
> > This fixes 9745, but not 10021 nor 11319.  I will keep plugging away on
> > this as time permits, trying to find patches for the other two that are
> > acceptable to everyone.
> 
> I looked at what goes wrong with PR 11319.

Thanks!

> The INSN for tr[j] = reg123 looks like this:
> 
> (insn 73 71 75 7 0x3027e300 (set (mem/s:SI (plus:SI (reg:SI 136)
>                 (const_int 32 [0x20])) [4 tr S4 A32])
>         (reg/v:SI 123)) 300 {*movsi_internal1} (nil)
>     (expr_list:REG_EQUAL (const_int 19 [0x13])
>         (nil)))
> 
> The INSN for reg138 = tr[0] looks like this:
> 
> (insn 86 126 87 8 0x3027e300 (set (reg:SI 138)
>         (mem/s:SI (plus:SI (reg/f:SI 31 r31)
>                 (const_int 40 [0x28])) [4 tr+0 S4 A128])) 300 
> {*movsi_internal1} (nil)
>     (nil))

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.

Dale's patch is "hackish" in the sense that it is correct, but papers
over the real problem -- that this assumption in the alias code is
wrong.  There's no reason that two base registers can't point to the
same place.

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.

Maybe there is some way to make sure that "p[0]" and "*p" are treated
the same way as "p[1]" when generating RTL, but that might well lead to
reduced performance as well.  Maybe, however, CSE would be able to fix
up the damage after the fact.

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]