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

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 Tue, Mar 20, 2018 at 9:29 AM, Jakub (Kuba) Kuderski via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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?
>
Clang does this for ABI's all the time.
Pointers to structs passed as i64, etc.

> 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.
>
While i'm a big supported of proper typing (because we are otherwise just
throwing valuable aliasing info away, and already suffer for it), people
seem to want to move in the other direction, and it would likely require a
stronger type system in LLVM anyway.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180320/1782858d/attachment.html>

> 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.
Besides the ones you and Daniel mentioned there's also GVN. If GVN  
concludes that a load of a pointer and a load of an integer are equal,  
e.g. (load i64**) = (load i64*), then it will get rid of one of the  
loads and insert an inttoptr/ptrtoint.
This is incorrect (in our memory model, at least), since GVN is  
essentially introducing implicit casts with the memory operations. One  
of the consequences of memory models that support implicit casts is  
that they make dead store eliminiation illegal in general, which is  
not really desirable (more details in the paper draft I sent you).

>> 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.
Sorry, most of the discussions were off-line.

Advantages include of disable type punning include:
  - Make LLVM IR (more) sound and thus enable automatic verification  
of optimizations
  - Enable additional optimizations. Daniel mentioned better AA. There  
are other things, like better tracking of padding.  In general,  
merging multiple variables in a single variable confuses most dataflow  
analyses.

Disadvtanges:
  - Potential for more insert/select element instructions (although  
fewer bitwise operations to pull out elements)
  - Need a few fixes to Clang for the ABI lowering stuff

I'm surely forgetting something, but that's what on the top of my head.

Nuno

On Wed, Mar 21, 2018 at 9:11 AM, Nuno Lopes via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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.
>>
>
> Besides the ones you and Daniel mentioned there's also GVN. If GVN
> concludes that a load of a pointer and a load of an integer are equal, e.g.
> (load i64**) = (load i64*), then it will get rid of one of the loads and
> insert an inttoptr/ptrtoint.
> This is incorrect (in our memory model, at least), since GVN is
> essentially introducing implicit casts with the memory operations. One of
> the consequences of memory models that support implicit casts is that they
> make dead store eliminiation illegal in general, which is not really
> desirable (more details in the paper draft I sent you).

Note:This is also illegal in non-integral pointer types, IIRC, and so as
that becomes less experimental, this has to be changed at least for that.



>
>
> 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.
>>
>
> Sorry, most of the discussions were off-line.
>
> Advantages include of disable type punning include:
>  - Make LLVM IR (more) sound and thus enable automatic verification of
> optimizations
>  - Enable additional optimizations. Daniel mentioned better AA. There are
> other things, like better tracking of padding.  In general, merging
> multiple variables in a single variable confuses most dataflow analyses.
>
> Disadvtanges:
>  - Potential for more insert/select element instructions (although fewer
> bitwise operations to pull out elements)
>  - Need a few fixes to Clang for the ABI lowering stuff
>
> I'm surely forgetting something, but that's what on the top of my
head.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180321/fa221179/attachment.html>