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

[Alex Bradbury via llvm-dev]

On 20 March 2018 at 10:28, Nuno Lopes <nunoplopes at sapo.pt> wrote:
>> 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.

But structures tend not to be handled as you would like for call
lowering, which is why the Clang frontend will often 'lie' about their
type to ensure that they are passed according to the ABI rules. I
think someone once described ABI/calling convention handling as
happening both too early and too late. You're forced to do some of the
work much earlier than you might expect - in your language frontend.
You then do the other half of the work in call lowering,
post-legalisation when structs have been split into their constituent
elements and illegal types have been split. It's surely not
insurmountable, but I expect a change here will require substantial
design and implementation effort, not to mention testing for
regressions.

I would like to see this improved in some way, but it's worth
recognising that going this route puts "fixing LLVM/Clang ABI
lowering" on the critical path. There hasn't been complete consensus
that there is a problem to fix, but even amongst those frustrated with
the status quo nobody has had the time to prototype an alternative
solution. Perhaps this extra potential benefit will help in that
respect.

> 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?

Honestly it's been a while since I looked at the handling of vectors
in call lowering.

Best,

Alex