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

[Nuno Lopes via llvm-dev]

> 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