On July 23, 2014 4:42:22 PM CEST, Jan Hubicka <hubi...@ucw.cz> wrote: >> On Tue, Jul 22, 2014 at 5:17 PM, Jan Hubicka <hubi...@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. >> 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. Yeah. Thanks, Richard. >Honza >> >> Richard. >> >> > Honza
