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

[Nuno Lopes via 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.

I just realized there isn't much information about this proposal. The  
best I could find is slides 23-24 of this:  
http://llvm.org/devmtg/2016-11/Slides/Lopes-LongLivePoison.pdf

The basic idea is that instead of accessing 2 shorts as i32, you could  
access them as <2 x i16>. In case of structures with different element  
types, you would need to use structures, which LLVM also supports. For  
the proposal to be correct, you can slice a value into smaller vector  
elements, but you cannot share a vector element across two values.
For example, representing you struct example as <8 x i8> would be  
correct, but not as <2 x i32>. Or we can use structures to have  
elements of the exact size.

You are right that the ABI lowering and the contracts for vectors are  
a bit underspecified. That's probably one of the reasons why vectors  
of i1s crash and generate bad code frequently. Is there padding  
between vector elements or not? Or are sub-word elements packed somehow?

Nuno