search for: d69477

...son)` whereas the optimized one is `f(nonnull poison)`. `f(nonnull poison)` should be UB because `f(nonnull null)` is UB. So, the transformation introduced UB. This optimization is correct if both `f(nonnull null)` and `f(nonnull poison)` are equivalent to `f(poison)`. 3. https://reviews.llvm.org/D69477 f(nonnull ptr); use(ptr); => llvm.assume(ptr != null); use(ptr); f(nonnull ptr); If f(nonnull null) is f(poison), this is incorrect. If ptr was null, the added llvm.assume(ptr != null) raises UB whereas the source may not raise UB at all. (e.g. assume that f() was an empty function) If f(nonnu...

...`f(nonnull poison)`. > `f(nonnull poison)` should be UB because `f(nonnull null)` is UB. So, the > transformation introduced UB. > This optimization is correct if both `f(nonnull null)` and `f(nonnull > poison)` are equivalent to `f(poison)`. > > > 3. https://reviews.llvm.org/D69477 > > f(nonnull ptr); > use(ptr); > => > llvm.assume(ptr != null); > use(ptr); > f(nonnull ptr); > > If f(nonnull null) is f(poison), this is incorrect. If ptr was null, the > added llvm.assume(ptr != null) raises UB whereas the source may not raise > UB at all....

...f which is a `ptrtoint` and therefore not really optimizer friendly. Dereferenceability, is even scarier. Thus, we are currently limited to (almost) boolean information when we want to manifest information in the IR (which happens due to inlining or code motion, see https://reviews.llvm.org/D69477 for an example). B) The one-use checks. Various pattern matching passes check the number of uses of a value. However, while `llvm.assume` is eventually eliminated by the backend it will still increase the use count of the operand. I doubt we are able to not increase the use count at all (a...

...null poison)` should be UB because `f(nonnull null)` is UB. > > So, the transformation introduced UB. > > This optimization is correct if both `f(nonnull null)` and > > `f(nonnull poison)` are equivalent to `f(poison)`. > > > > > > 3. https://reviews.llvm.org/D69477 > > > > f(nonnull ptr); > > use(ptr); > > => > > llvm.assume(ptr != null); > > use(ptr); > > f(nonnull ptr); > > > > If f(nonnull null) is f(poison), this is incorrect. If ptr was null, > > the added llvm.assume(ptr != null) raises U...

...t really > > optimizer friendly. Dereferenceability, is even scarier. Thus, we are > > currently limited to (almost) boolean information when we want to > > manifest information in the IR (which happens due to inlining or code > > motion, see https://reviews.llvm.org/D69477 for an example). > > > > B) The one-use checks. > > Various pattern matching passes check the number of uses of a value. > > However, while `llvm.assume` is eventually eliminated by the backend > > it will still increase the use count of the operand. I doubt we a...

...because `f(nonnull null)` is UB. > > > So, the transformation introduced UB. > > > This optimization is correct if both `f(nonnull null)` and > > > `f(nonnull poison)` are equivalent to `f(poison)`. > > > > > > > > > 3. https://reviews.llvm.org/D69477 > > > > > > f(nonnull ptr); > > > use(ptr); > > > => > > > llvm.assume(ptr != null); > > > use(ptr); > > > f(nonnull ptr); > > > > > > If f(nonnull null) is f(poison), this is incorrect. If ptr was null, > > &...

...imizer friendly. Dereferenceability, is even scarier. Thus, we are > >>> currently limited to (almost) boolean information when we want to > >>> manifest information in the IR (which happens due to inlining or code > >>> motion, see https://reviews.llvm.org/D69477 for an example). > >>> > >>> B) The one-use checks. > >>> Various pattern matching passes check the number of uses of a value. > >>> However, while `llvm.assume` is eventually eliminated by the backend > >>> it will still increase th...