[PATCH] D65118: Analysis: Don't look through aliases when simplifying GEPs.

Johannes Doerfert via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jul 23 04:25:11 PDT 2019


jdoerfert added subscribers: sanjoy, reames.
jdoerfert added a comment.

In D65118#1596838 <https://reviews.llvm.org/D65118#1596838>, @pcc wrote:

> - The only case in which we can soundly replace an alias with the aliasee is when we know that both have the same value.


That is why I thought the "FollowAliases" versions could still look through aliases if they have an "exact definition".

> - However, there's still a benefit in looking past aliases, but only in order to look at the *contents* (not the address) of the global.
> - For example, the following is valid:
> 
>   @a = private constant i8* @x
>   @b = linkonce_odr alias @a
>   
>   define void @foo() {
>     %x = load i8*, i8** @b
>     ret i8* %x ; may be replaced with ret i8* @x
>   }

Mh, this is not what I expected to be valid. To me, this looks like the classical "non-exact-definition" problem that breaks inter-procedural reasoning (@sanjoy, @reames).
What happens if I modify the example a bit:

>   @a = private i8 @x
>   @b = linkonce_odr alias @a
>   
>   define i1 @always_true() {
>     store i8 0, i8* @a
>     %x = load i8, i8* @b
>     ... ; @b and @a are not modified here but other globals might be
>     %y = load i8, i8* @b
>     ... ; @b and @a are not modified here but other globals might be
>     %cmp = icmp eq %x, %y
>     ret i1 %cmp
>   }

I would assume `always_true` to return "always" `true`, no matter the value of `@b`.
However, if we look through `@b` once (say for `%x`) and then replace it at link time
with a different alias, couldn't `%y` result in a different value?

> [...]
> 
> - So I think that the ideal final state is that looking past aliases should be opt-in and only allowed when a pass introduces no dependencies on the address of the aliasee.

So, should we make "NoFollowAliases" the default and add the option/variants that "FollowAliases" instead?


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65118/new/

https://reviews.llvm.org/D65118





More information about the llvm-commits mailing list