[PATCH] D96663: [InstCombine] Fold nonnull (select c,null,p) to nonnull p
Sanjay Patel via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Feb 22 07:11:42 PST 2021
spatel added a comment.
In D96663#2578084 <https://reviews.llvm.org/D96663#2578084>, @aqjune wrote:
> In D96663#2577600 <https://reviews.llvm.org/D96663#2577600>, @spatel wrote:
>
>> The code duplication suggests that we should have a common place for this logic (especially if it already exists in SimplifyCFG).
>> Could it be added to ValueTracking's isKnownNonZero() or wrap around that?
>> It might already be in there under isKnownNonNullFromDominatingCondition(), but we need to fix it up to deal with selects?
>
> Hmm, as you said, adding the "assume((select cond, null, p) != null)" pattern to isKnownNonZeroFromAssume seems enough?
> Compiling the Rust code snippet from pr48975 already creates llvm.assume: https://godbolt.org/z/8KxWKP
> That being said, it might be a good idea to update `passingValueIsAlwaysUndefined` to check `CB->paramHasAttr(ArgIdx, Attribute::Dereferenceable)` as well because `dereferenceable` is quite common. `dereferenceable` implies `noundef`, so it is valid to assume that passing null to `nonnull dereferenceable` is UB. What do you think?
If we can make the value tracking analysis better without adding or relying on llvm.assume, that would be best. I'm not sure about the current thinking on assume intrinsics, but we had found cases where the extra instructions/uses were interfering with optimization rather than helping. We've also seen cases like https://llvm.org/PR49171 where the cost of analyzing assumes is extreme. Not sure if those problems are overcome by assume bundles:
https://llvm.org/docs/LangRef.html#assume-operand-bundles
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D96663/new/
https://reviews.llvm.org/D96663
More information about the llvm-commits
mailing list