This is the mail archive of the
mailing list for the GCC project.
Re: should MEM tracking be able to optimize this?
- From: Daniel Berlin <dan at cgsoftware dot com>
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 18 Nov 2001 00:08:46 -0500
- Subject: Re: should MEM tracking be able to optimize this?
On Saturday, November 17, 2001, at 11:40 PM, Richard Kenner wrote:
> It's not that simple to differentiate between field accesses, and
> whether two given field accesses overlap.
> True in general, but you don't need to solve the general problem. You
> just need an algorithm that tells you when it's known they *don't*.
Errr, this is still may-alias info, either way.
> And it's not hard to find such an algorithm that will do that in the
> vast majority of all the common cases.
Only if we are talking about interprocedural algorithms.
Intraprocedural aliasing algorithms will never get the vast majority of
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
> The tricky part isn't in determining that two fields don't overlap,
> but in all the all recordkeeping needed to have that information at
> the right place.
It's not actually all that tricky to do that either, it's just nobody
had ever bothered to do it.
Of course, doing it at the RTL level would be pointless (since we've
lost all the useful info by then), which is why i had done it at the
tree level, and used it in tree level optimizations.
I also never bothered to try to transfer it down to the RTL level.