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]

Re: MEM flags and stack temps

>     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.

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