[llvm-dev] What is the status of the "Killing Undef and Spreading Poison" RFC?
Nuno Lopes via llvm-dev
llvm-dev at lists.llvm.org
Tue Mar 20 02:39:28 PDT 2018
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
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
Quoting Benoit Vey via llvm-dev <llvm-dev at lists.llvm.org>:
> Back in 2016 an RFC titled "Killing Undef and Spreading Poison" 
> 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"  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 .
> 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
> : https://lists.llvm.org/pipermail/llvm-dev/2016-October/106182.html
> : https://www.cs.utah.edu/~regehr/papers/undef-pldi17.pdf
> : https://reviews.llvm.org/D29011
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
More information about the llvm-dev