[PATCH] D71960: [Attributor] AAUndefinedBehavior: AAValueSimplify in memory accessing instructions.

Hideto Ueno via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Dec 28 10:21:20 PST 2019


uenoku added a comment.

In D71960#1797992 <https://reviews.llvm.org/D71960#1797992>, @baziotis wrote:

> Now, the more interesting part is actually looking what the Attributor does. If I followed the code correctly, previously we didn't query `AAValueSimplify`.
>  What happens if we do (and correct me if I'm wrong, it seems useful to me to know how it works) is that `%e.2` is a floating value,
>  which calls `genericValueTraversal()`, which for the `phi` node, calls `VisitValueCB` with the 3 incoming values: `null`, `undef` and `undef`.
>  This in turn calls `checkAndUpdate()` which ignores `UndefValue` and finalizes on `null` (but if we had other different values, this:
>
>   if (AccumulatedSimplifiedValue.hasValue())
>     return AccumulatedSimplifiedValue == QueryingValueSimplified;
>   
>
> in `checkAndUpdate()` would return `false` because of conflicting values, effectively indicating pessimistic fixpoint).
>
> Now, other than that, I guess that with this:
>
> > So once `AAIsDead` can get to interact with `AAUB`, the problem will be solved.
>
> you meant that when `AAIsDead` will interact with `AAUB`, the former will ignore the 2 `phi`s in `genericValueTraversal()` since it will consider them dead.


Yes, exactly. Btw, my understating is that `load` inst from `undef` pointer causes UB even if "null-pointer-is-valid"="true" (https://llvm.org/docs/LangRef.html#pointeraliasing). 
Then, I think `@fn_no_null_opt ` can be optimized aggressively, is this correct? If so, please add `FIXME`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71960





More information about the llvm-commits mailing list