llvm dev - Aug 2021 - [llvm-reduce] Reduction to undef/poison/null?

Nicer because it's less likely to introduce new UB? Or some other reason?

I /guess/ undef because it's more vague/shows the value doesn't matter
to
some degree?

(might be worth CC'ing some of the other folks who've contributed
patches/implemented llvm-reduce - not everyone reads llvm-dev or does so
frequently enough to see relevant threads in a timely manner)

On Mon, Aug 30, 2021 at 10:50 AM Arthur Eubanks via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Currently in llvm-reduce when we try to remove instructions, we'll RAUW
> them with undef. But it seems nicer to have the final IR use null values
> (e.g. 0, zeroinitializer, etc) rather than undef. Should we attempt to use
> null values? Or why undef over poison?
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210830/8c786374/attachment.html>

> On 30 Aug 2021, at 19:59, David Blaikie via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Nicer because it's less likely to introduce new UB? Or some other
reason?
> 
Using undef/poison is problematic, because there are multiple ways this could
cause new UB (e.g. branch on undef, passing poison/undef to a function with a
noundef argument).

I’m not sure if using zero will work well in certain cases, because it can
introduce UB as well (e.g. load from null, passing as nonnull argument).

I think ideally we would have a way to materialise values we know nothing about,
but are not undef. Perhaps we could add some oracle function, but that would
come with its own drawbacks.

Cheers,
Florian