[PATCH] [PR16236] Be conservative when doing TypeBasedAlias Analysis of members of Struct

[Dan Gohman]

On Tue, Apr 8, 2014 at 5:04 AM, Karthik Bhat <kv.bhat at samsung.com> wrote:

> Hi majnemer, sunfish, rengolin,
>
> Hi All,
> This patches fixes PR16236 aproblem with TypeBasedAlias Analysis. Below is
> my understanding please help me review this patch and if i'm thinking in
> the right direction.
> The problem in this case seems to be that in case we have an union like -
>   union
>   {
>     short f0;
>     int f1;
>   } u, *up = &u;
>
> f0 and f1 may alias each other. But while constructing AliasSet for these
> in TypeBasedAlias Analysis during PathAliases we see that both the MDNodes
> corresponding to (f0 and f1) are not ancestor of each other and have a
> common root and thus conclude that they will Not alias each other. But in
> case of union this may not be correct f1 anf f0 may alias each other as
> thye operate on same underlining memory location.
>

LLVM's approach for solving this problem is to do a BasicAA query first,
and if BasicAA says MustAlias or PartialAlias, it doesn't do a TBAA query
at all. This represents a kind of "best effort": the optimizer will make
its best effort to discover whether the type information is unreliable, but
if it doesn't discover a problem, then it assumes that the type information
is reliable. As such, it's not safe in all cases, but the C standard's own
definition of TBAA is not safe in all cases, and this is an attempt to
implement the spirit of what the C standard desired while finding a
practical balance with correctness.

Are you seeing a case where this approach is not sufficient?


> In this patch we check that if both correspond to StructTyID type we
> evaluate it conservatively so that we do not incorrectly conclude that
> these two types are NoAlias.
>

This is not safe, since pointers can be bitcasted to pointer types with
arbitrary pointees.

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140408/eee06231/attachment.html>