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

[Alex Bradbury 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.

Best,

Alex