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

[Daniel Berlin via llvm-dev]

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>