[PATCH] D90529: Allow nonnull/align attribute to accept poison

Johannes Doerfert via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Mar 1 09:00:45 PST 2021


jdoerfert added a comment.

In D90529#2594026 <https://reviews.llvm.org/D90529#2594026>, @aqjune wrote:

> While writing a LangRef patch for the semantic changes in nonnull & align attributes in assume operand bundle, I found one interesting case. :)
>
> Creating assume from these two calls yields the same result:
>
>   call void @hi1(i8* nonnull %val, i8* noundef %val)
>   call void @hi2(i8* nonnull noundef %val)
>
> They both generate:
>
>   call void @llvm.assume(true)["nonnull"(i8* %val), "noundef"(i8* %val)]
>
> A question is whether this assume is UB if, say, %val is `inttoptr(1)`.
> Creating this assume from `call void @hi2(%val)` is okay because `call void @hi2(%val)` is already UB.
> But, creating the assume from `call void @hi1(%val, %val)` isn't okay! `%val` is non-null and noundef, so the call is fine.
>
> To distinguish these two, what about this?
> (1) simply use UB semantics for nonnull attribute in assume operand bundle
> (2) lower `nonnull` attribute in the call-site into `nonnull` bundle only if it is accompanied with `noundef`.
> Then, we don't need to change anything about nonnull from LangRef: the current text is defining it as UB (https://llvm.org/docs/LangRef.html#assume-operand-bundles ).

I thought at first (2) is the way to go but then I asked myself if `@hi1(%val, %val)` is really not already UB. The question is, does `val` become poison for this use or is `val` poison in the scope of the use. I feel the latter is what we actually want. If we assume this is the only call of `hi1` and we then do interprocedural transformations to replace the use of the first argument with the second or vice versa, would that be illegal because of the attribute mismatch or allowed? If it is the latter, the call must have been UB.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90529



More information about the llvm-commits mailing list