[PATCH] D85184: [Attributor][WIP] Deduce noundef attribute

Juneyoung Lee via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 5 12:34:49 PDT 2020


aqjune added a comment.

In D85184#2195428 <https://reviews.llvm.org/D85184#2195428>, @jdoerfert wrote:

> In D85184#2195356 <https://reviews.llvm.org/D85184#2195356>, @aqjune wrote:
>
>> BuildLibCalls.cpp 's inferLibFuncAttributes seems to be the right place for this?
>> I'll start with adding noundef to return values of library functions.
>
> That would be great, and yest that is the right place for most of it IIRC.

I made D85345 <https://reviews.llvm.org/D85345>.
Rather than adding noundef to all library functions' return values, I chose standard I/O functions and added noundef to its return values / arguments instead.
The reason is that some functions did not seem to be clear whether its return value is noundef.
`memcmp` is one example. `(load p) - (load q)` can be folded into `memcmp(p, q, bytesz)`, but the former expression can be poison or undef whereas the latter one raises UB in that case.

>> I think it is safer to
>
> Safer than what?

(than adding noundef to all library functions' args :)

>> gradually add noundef to arguments of library functions, since it may cause end-to-end miscompilation (if there exists any incorrect transformation): IIRC there was a regression from strlen having nonnull attribute at its pointer argument, that happened from its interaction with llvm.assume.
>
> I wouldn't be totally surprised if something explodes but it should not and it is good to know earlier if it does ;)

Yes, me too.


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

https://reviews.llvm.org/D85184



More information about the llvm-commits mailing list