This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Trivial cleanup
- From: Michael Matz <matz at suse dot de>
- To: Jeff Law <law at redhat dot com>
- Cc: Andrew MacLeod <amacleod at redhat dot com>, Paolo Carlini <paolo dot carlini at oracle dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 1 Oct 2013 15:12:06 +0200 (CEST)
- Subject: Re: [PATCH] Trivial cleanup
- Authentication-results: sourceware.org; auth=none
- References: <5243025E dot 8050101 at redhat dot com> <52430544 dot 8030005 at redhat dot com> <524305C3 dot 3050003 at oracle dot com> <5243086D dot 3030806 at redhat dot com> <alpine dot LNX dot 2 dot 00 dot 1309261605360 dot 11100 at wotan dot suse dot de> <524511A4 dot 4030808 at redhat dot com> <5246E84A dot 5090105 at redhat dot com> <5249AB53 dot 3020804 at redhat dot com>
On Mon, 30 Sep 2013, Jeff Law wrote:
> > - the compiler better do an awesome job of sharing stack space for
> > user variables in a function... I wouldn't want to blow up the stack
> > with a bazillion unrelatd temps each wit their own location.
> If the objects have the same type and disjoint lifetimes, they can be easily
> Things are more difficult if the types are different
Not anymore. We adjust the alias machinery when merging differently typed
variables into the same stack slot, see update_alias_info_with_stack_vars.
> -- IIRC, the root
> of the problem is the optimizers can interchange a load of one type with
> a later store of the other -- the aliasing code says "hey, they're
> different types, so they don't alias, feel free to move them around as
> desired" and all hell breaks loose.
That was the problem once, yes. Meanwhile we should have fairly decent
stack slot reuse, especially with variables declared in different scopes
(since the end-of-scope CLOBBERs), for non-SSA_NAME temps that is. For
the others it's the register allocator anyway that has to do a decent job
(and it does).