[llvm-dev] What is the status of the "Killing Undef and Spreading Poison" RFC?

[Nuno Lopes via llvm-dev]

Hi,

Let me give you my view of the status:
The proposal you mentioned was, I believe, well understood and  
accepted. Except for one bit, which was that it requires correct  
typing of load/store operations. That is, if you load an i32, it means  
you are loading a single 32-bit integer, not two 16-bit integers or  
something else.

This is a valid concern because currently nor LLVM nor clang respect  
this property. Clang may pass several parameters as a single variable,  
LLVM has optimizations that combine several loads into a single  
integer load, etc.
So in some places of LLVM it is assumed that ix is just a bag of x  
bits and not an integer of x bits.

My personal opinion is that we should fix LLVM/clang such that memory  
operations are properly typed. We have proposed this through the use  
of vectors. While there were supporters for this approach, there  
wasn't a consensus.  To be fair, we didn't implement a complete  
prototype for this idea nor did we conduct a thorough discussion.

Right now Sanjoy is working off-list on an alternative proposal, which  
is to have bit-wise semantics for poison. This removes the constraint  
that memory operations need to be well typed. This proposal is not  
ready yet AFAICT, but it will be presented and discussed once it is :)

BTW, allowing the compiler to introduce type-punning memory operations  
is actually wrong when implicit integer-to-pointer casts are  
introduced. Nevertheless, one can argue that it is a smaller problem  
to fix than fixing all incorrectly-typed memory operations.

I hope this helps. Let me know if you have further questions.   
Unfortunately I cannot offer any timeline on when this issue will be  
fixed.

Nuno


Quoting Benoit Vey via llvm-dev <llvm-dev at lists.llvm.org>:

> Hi,
>
> Back in 2016 an RFC titled "Killing Undef and Spreading Poison" [1]  
> was posted on this mailing list, which generated a lot of discussion  
> between different people. Later in 2017, a paper titled "Taming  
> Undefined Behavior in LLVM" [2] was published, detailing the various  
> concerns introduced in the RFC. There is also a patch proposal with  
> an initial implementation of the `freeze` instruction on the LLVM  
> review website [3].
>
> As far as I can see, there has been no public activity on that  
> matter since mid-2017. What is the current status?
>
> Thanks, Benoit
>
> References:
> [1]: https://lists.llvm.org/pipermail/llvm-dev/2016-October/106182.html
> [2]: https://www.cs.utah.edu/~regehr/papers/undef-pldi17.pdf
> [3]: https://reviews.llvm.org/D29011
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev