On Mon, 3 Feb 2014, Jakub Jelinek wrote: > On Mon, Feb 03, 2014 at 09:51:01AM +0000, Bingfeng Mei wrote: > > If it is just for C++ placement new, why don't implement it as a lang_hook. > > Now other languages such as C have to be made conservative and produce worse > > code.
But if you combine a C++ and a C unit with LTO then what do you do? Aliasing is a thing that needs to be fully defined from within the middle-end. > Even in C++ code you don't use placement new that often, so e.g. by having > the placement new explicit through some special GIMPLE statement in the IL, > you could e.g. just look if a particular function or loop contains any > placement new stmts (cached in struct function and loop?) and use TBAA if > it isn't there. I'd say that's a hack. We've been there before and we've failed miserably. Note that the current memory model allows unions to no longer have alias-set zero thus it _improves_ TBAA (ok, unions still _do_ have alias-set zero because the RTL oracle doesn't correctly handle offset-based must-aliases). Changing that would probably help GCC itself a lot. [this isn't about punning through unions but about changing the active member by storing into it, something code usually doesn't do but it still gets pessimized because it could] Note that for the case in question the patch I proposed still can help some code - also the vectorizer, as opposed to the generic data-dependence code, can impose additional constraints because it knows the vectorized loop body contains at least two scalar iterations. And note that for the case in question we can derive non-aliasing because with p[i] += q[i]; p[i] is both read _and_ written in the same iteration thus it cannot have the dynamic type of q[i] before it's stored into. Of course data-dependence doesn't do this kind of analysis currently, but it certainly could. Arguing to change how we handle placement new (same issues arise with anonymous storage and memcpy in C!) is throwing out the baby with the bathwater. Richard.
