This is the mail archive of the gcc-patches@gcc.gnu.org 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: PATCH: tree-ssa-sink breaks stack layout


On Wed, Apr 1, 2009 at 2:26 PM, Sandra Loosemore
<sandra@codesourcery.com> wrote:
> Daniel Berlin wrote:
>
>> This is independent of the fact that it's clearly missing an aliasing
>> conflict above.
>> Then again, I have no dog in this fight, I can happily wait till you
>> fix this with live range info and then discover it's still borked
>> because it is using alias information wrong :)
>
> I was mulling this over again, and I think Daniel may be onto something
> here.
>
> In the abstract, when you're attempting to do code motion of a statement
> that involves a memory write, you need to examine all the intervening
> statements that do memory reads to see if they may reference the same
> location. ?One of the most basic rules in alias analysis is typically that
> references to different objects cannot alias, and that different local
> variables are different objects.
>
> The stack sharing is breaking that assumption. ?As I've said, that's an
> important optimization and we can't disable it entirely. ?So now it seems to
> me that the more correct place to address this is by making the alias
> analysis more conservative: ?different local variables are known to be
> different objects only when they are both visible in the same lexical scope.
>
> Thoughts on that? ?Maybe I'm totally off-base here.... ?I've previously done
> a lot of work on alias analysis and code motion in another compiler, but I'm
> still relatively unfamiliar with gcc internals.

I think this may well work - but of course it requires the RTL optimizers not
only to consult the type-based aliasing machinery as it does now.  It also
would require that if you do not know which base object you are accessing
you have to punt completely.

Another possibility would be to delay stack slot allocation until after all
RTL code motion is finished at which point the lifetimes of all stack-locals
is fixed (which it in practice is not at expansion time).

Thus, if the problem is tackled only at expansion time we still need some
sort of barriers to prevent RTL optimizers from making life-ranges overlapping
again (or defer to the may-alias kludge we have now).

Richard.

> -Sandra the trying-to-learn-as-she-goes-along
>
>


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