This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Strenghten assumption about dynamic type changes (placement new)
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, Jason Merrill <jason at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 23 Jul 2014 16:42:22 +0200
- Subject: Re: Strenghten assumption about dynamic type changes (placement new)
- Authentication-results: sourceware.org; auth=none
- References: <20140708135023 dot GC27691 at kam dot mff dot cuni dot cz> <53C87213 dot 1050604 at redhat dot com> <20140718100335 dot GA7671 at kam dot mff dot cuni dot cz> <53CA76FF dot 8080101 at redhat dot com> <20140719154408 dot GA8665 at kam dot mff dot cuni dot cz> <CAFiYyc0hDA+9G+wBVkf8Gif8vsDdpvyf4r3X8P=7G-P=QaWwqQ at mail dot gmail dot com> <20140722135434 dot GA12329 at kam dot mff dot cuni dot cz> <CAFiYyc37YkpYFGX2WJ14BUyEQ5k6ggvLrntsemtMEmat+6RgXA at mail dot gmail dot com> <20140722151720 dot GA25121 at kam dot mff dot cuni dot cz> <CAFiYyc0o5mRFF3V_nFBX5+TSDNKT9=BfqoUj6xN=gaNiY+UJuA at mail dot gmail dot com>
> On Tue, Jul 22, 2014 at 5:17 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
> >> I don't see why
> >>
> >> long x[1024];
> >>
> >> Q *q = new (x) Q;
> >> q->~Q ();
> >> new (x) T;
> >>
> >> would be invalid. I also don't see why
> >>
> >> Q q;
> >> q.~Q ();
> >> new (&q) T;
> >>
> >> would be. Object lifetime is precisely specified and I don't see where it is
> >> tied to (static) storage lifetime.
> >
> > This is precisely the testcase I posted on beggining of this thread.
> >
> > I do not see how the testcases can work with aliasing rules in the case Q's and T's
> > memory is known to not alias.
>
> It works because of the well-defined memory model (with regarding to
> TBAA) in the middle-end. Every store changes the dynamic type of
> a memory location which means that you can only use TBAA for
> true-dependence checks (not anti-dependence or write-dependence
> checks).
I see, I did not notice this change - it seems like quite a big hammer though,
limiting scheduling (and loop opts) quite noticeably for all languages. Are
there any other motivations for this besides placement new?
>
> That has been the way we operate since GCC 4.3 (if I remember
> correctly). That's also the reason we don't have to special-case
> unions in any tricky way (yeah, we still do - because of that
> type-punning special case and RTL alias analysis not dealing with it).
>
> > Either we need to define what is and is not supported or go for speculative devirt more often.
>
> The GCC middle-end (which also has to deal with cross-language
> cases!) has this specified very clearly.
Yep, the cross language support is bit more limited when you speak of
polymorphic types. But indeed with the aliasing "hack" above I can
imagine one can destroy one object and build new one on a given location.
I will push things towards speculative types to allow implementing super-safe
devirt and we could have flag strenghtening assumptions declaring that placement
new is not used to change polymorphic type to other polymorphic type and we can
see hw important it is in practice.
Honza
>
> Richard.
>
> > Honza