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

Tue Mar 20 09:29:21 PDT 2018

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>