Re: [PATCH][RFC] Adjust the middle-end memory model

[Richard Guenther <rguenther at suse dot de>]

On Fri, 8 May 2009, Richard Guenther wrote:

> 
> This adjusts the middle-end memory model to properly honor type-based
> aliasing rules set by the C and C++ standards.
> 
> The bulk of the patch gets rid of our previous attempts to fix
> the issues around placement new and friends, CHANGE_DYNAMIC_TYPE_EXPR
> and DECL_NO_TBAA_P.  The core pieces are separated in the changelog.
> 
>  - We no longer prune points-to sets using TBAA (there is no noticable
>    slowdown because of this in SPEC 2000 or SPEC 2006).  This is
>    because we need unpruned points-to sets to compute anti and
>    output dependencies.  We could keep both pruned and unpruned sets,
>    but the only differences should be in disambiguating two accesses
>    via pointers.  Another advantage is that we can re-activate
>    merge_alias_info again with unpruned sets.
> 
>  - The instruction scheduler (or rather, anti_dependence and
>    output_dependence) no longer can use TBAA information.
> 
>  - The tree alias oracle got similar functionality, refs_anti_dependent
>    and refs_output_dependent and the tree level data dependence
>    analysis code makes use of these.
> 
> What remains to be done?
> 
>  - The alias warning code during points-to analysis needs to be
>    re-done again.  It relies on the availability of pruned points-to sets.

It looks like fixing the current flow-insensitive warning code will
not be particularly helpful as it will cause (as it does now) false
positives once you use placement new in C++.

Instead a flow-sensitive variant should be implemented and the
C frontend implementation be enhanced to warn about (the invalid in C
but valid in C++) type-punning of decls with a declared type.

I do not have time to do this at the moment but will file an
enhancement request and queue it in my TODO.

Thus, stay tuned for the final patch (appearantly there are no
objections in general looking at the responses to the original mail).

Thanks,
Richard.