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

[Daniel Berlin via llvm-dev]

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>