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

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

> 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

Hi Nuno,

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.

What are the places in llvm and clang that do this kind of type punning? So
far I only encountered them in SROA and in memcpys generated by clang. I
would be very interested in getting rid of them.

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

Would you be able to post a link to these discussions? I would like to
understand the potential cons of such change.

Best,
Jakub

On Tue, Mar 20, 2018 at 6:28 AM, Nuno Lopes via llvm-dev <
llvm-dev at lists.llvm.org> 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.
>
> 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
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>


-- 
Jakub Kuderski
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180320/f3304018/attachment-0001.html>

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