This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Speedup alias analysis [patch]
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Chris Lattner <sabre at nondot dot org>
- Cc: Diego Novillo <dnovillo at redhat dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: 24 Jun 2003 20:31:34 -0400
- Subject: Re: [tree-ssa] Speedup alias analysis [patch]
- References: <Pine.LNX.4.44.0306241817200.14119-100000@nondot.org>
On Tue, 2003-06-24 at 19:21, Chris Lattner wrote:
>
> Diego Novillo wrote:
> > ADDR_EXPR is a funny operator. If you expose it in the IL you may run
> > into aliasing problems and the optimizers will likely mess things up.
> ...
> > If we were to expose it into the IL we would have to teach the
> > optimizers to treat it with care. I'm not sure I want that. This topic
> > comes up every now and then. We still haven't found a more gracious way
> > of dealing with ADDR_EXPRs, unfortunately.
>
> LLVM does not have an "address-of" operator in the language, and handles
> all of the issues you brought up gracefully. If you'd like to describe
> how we handle these issues, I would be glad to...
>
If I recall, dont you simply treat all locals and such as pointers? so
int a; is treated like 'int *a = alloca(sizeof(int))' so you never have
to take its address, it gets its 'default' memory location on the
stack. Then if you take the address of 'a', and assign it to a
pointer, you really just copy your pointer to 'a', since thats all you
have anyway. If you have a = 10; you see it as *a = 10;
Do I remember that correctly? :-)
Andrew