This is the mail archive of the 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: should MEM tracking be able to optimize this?

On Sunday, November 18, 2001, at 07:31  AM, Richard Kenner wrote:

>     Only if we are talking about interprocedural algorithms.
>     Intraprocedural aliasing algorithms will never get the vast 
> majority of
>     common cases.
>     But assuming we are talking about interprocedural algorithms, you 
> are
>     right of course.  aliasing algorithms generally are distinguished 
> by how
>     much info they retain at a given program point, and their alias 
> relation
>     representation.
> No, that's way more complex than I mean.  The point is that there are
> times (such as this case and many other similar ones) when you can
> tell statically that certain types of references to field can never
> conflict (because the bit positions don't overlap).  The problem is
> representing this information in such a way that you can make that
> statement about the references themselves.
> Recall the example was:
> 	struct foo { float a[2048], b[2048]; }
> It's obvious statically that X.a[i] and Y.b[j] can never conflict for 
> any
> expressions X and Y of type struct foo.  But there needs to be a way to
> represent this.
Well, these are easy cases, to be honest.

If I remember one alias algorithm i read a while ago, you can assign 
each field a unique name.
All fields in a union are assigned the *same* name (IE you generate one 
unique name, and use it for all of them), to show that they overlap.

You could also add stride, and use it to say they can't ever conflict.


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