This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: MEM flags and stack temps
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Subject: Re: MEM flags and stack temps
- From: Joe Buck <jbuck at synopsys dot COM>
- Date: Thu, 16 Nov 2000 14:22:08 -0800 (PST)
- Cc: gcc at gcc dot gnu dot org
> You seem to be thinking of a completely different problem. Is this an
> issue with the ordering of the passes?
>
> Yes. The idea is that you want to keep stack slots as RTL objects as
> long as possible to do optimizations on *them*. But when you actually find
> you *do* need them, you have to address them. If the offset to address them
> is large enough, that offset calculation itself would need to be cse'd
> and moved out of loops.
This is possibly naive, since I'm not familiar enough with the relevant
back end structures. But what if the offset calculation showed up as
its own RTL object, computing an address-register-like pseudo which is in
turn "read" by the addressof(stack slot) construct? It would then be
cse'd, and if all of the addressof's for that stack slot are removed,
these offsets would then be dead, and eliminated by dce.
The idea is that they'd be cse'd and moved out of loops on the assumption
that they are needed, and if it turns out that they aren't then they
will be killed.