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: Richard Biener <richard dot guenther at gmail dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: Jason Merrill <jason at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 24 Jul 2014 10:28:26 +0200
- Subject: Re: Strenghten assumption about dynamic type changes (placement new)
- Authentication-results: sourceware.org; auth=none
- References: <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> <20140723144222 dot GA23992 at kam dot mff dot cuni dot cz> <3aa8219d-8bde-4a69-afbd-97bf15396bf2 at email dot android dot com> <20140723162951 dot GA28234 at kam dot mff dot cuni dot cz>
On Wed, Jul 23, 2014 at 6:29 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> On July 23, 2014 4:42:22 PM CEST, Jan Hubicka <hubicka@ucw.cz> wrote:
>> >> 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?
>>
>> Aggregate copies and memcpy transferring the dynamic type for example. Being able to tbaa union accesses for another. And yes, placement new.
>>
>> It's not so much an optimization preventing thing as you still can move loads up and stores down with the help of tbaa.
>
> well, but you lose extra parallelism like
>
> *shortptr = exp
> <longer dependency chain with shortptr>
> var = *shortptr
> *intptr = exp
> <longer dependency chain with intptr>
> var = *intptr
Yes (that is, you can't hoist the *intptr = exp store above the var = *shortptr
load with TBAA only). You can probably still hoist the <longer dependency
chain with intptr>, it's not clear from your example.
That said, being able to optimize union accesses with TBAA at all
is still nice (esp. for GCC). Now, the C frontend still forces alias-set zero
for this case because of the RTL alias oracle disfunctionality which doesn't
treat a must-alias as an alias if it can TBAA disambiguate.
Richard.
> Honza