This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: Fix PR2758
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Subject: Re: PATCH: Fix PR2758
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Tue, 12 Jun 2001 13:17:41 -0700
- cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
--On Tuesday, June 12, 2001 02:31:47 PM +0000 Richard Kenner
<kenner@vlsi1.ultra.nyu.edu> wrote:
> Yup, I wrote it. But, here we have structures, and they are
> in alias set zero, so the slots do get reused.
>
> I don't follow. If the type is alias set zero, then yes they get reused
> but they can't conflict.
Right. Until we start labeling pieces of them with non-zero alias
sets, which is what we did.
Imagine code like this:
struct S { int i; }
struct T { float f; }
Please assume that `int' and `float' have the same size. Maybe there
are more members, too, it doesn't matter, as long as we decide to
assign instances of these structs to the same slot. Now, we have:
{ S s; s.i; }
{ T t; t.f; }
Obviously, you want to actually do something with the data, but you
get the idea.
Now, `s' and `t' both have the same slot, and it has alias set zero.
But, with the old code `s.i' has the alias set for `int' and `t.f' has the
alias set for `float'. Oops, that's just as bad as putting two things
with the same alias set in the same slot. Unless we can prove that
`s' is not in a shared stack slot, we cannot assign an alias set to
`s.i'.
As I said, it is perhaps safe to look at the MEM for the `s' and
see if it has alias set zero. If it does not, then it can only share
a stack slot with the other things of the same type; in that case,
it is probably safe to assign an alias set for the field.
> in that case. This code can't be doing anything there are some things
> that are *not* in alias set zero that are reused, and that's wrong.
Sorry; I can't follow that sentence.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com