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

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

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

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

On 20 March 2018 at 09:39, Nuno Lopes via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 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.
Do you have a link to this vector-based proposal? Suppose Clang
currently lowers a parameter of type struct { int32_t, int8_t, int8_t,
int8_t, int8_t } to i64, neither changing this to <8 x i8> or <2 *
i32> seems correct - but perhaps one of those options is close enough
for your requirements?. This is a disruptive change of course: there
is an often under-specified contract between the frontend and target
backend on the ABI lowering of function parameters and return values.
Changing the requirements here will require changes for every LLVM
language frontend. If a big shake-up of this part of LLVM is the way
forwards, it would probably be worth taking the time to consider all
possible options for improvement.

Best,

Alex