[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