[llvm-dev] [GSoC] Fixing fundamental issues in LLVM IR

[David Chisnall via llvm-dev]

Hi,

This project looks very interesting.  Would you be able to describe a 
bit how this intersects with the opaque pointer work?  Your motivating 
example would lose the bitcasts with opaque pointer but, if I understand 
correctly, the underlying issue remains and would just be more obvious 
with opaque pointers.

The SelectionDAG impact also looks interesting.  In the CHERI back ends, 
we have to be very careful in the lowering because loads / stores of 
integers do not carry pointer provenance and so will lose the tag bits 
if used to copy structures that contain pointers.  If we could 
differentiate between a 128-bit integer copy and a 128-bit 
type-oblivious copy (which must conservatively go via capability 
registers if it is 128-bit aligned) then that would probably lead to 
better codegen.

David

On 25/05/2021 07:10, George Mitenkov via llvm-dev wrote:
> Hi all,
> 
> My proposal "Fixing fundamental issues in LLVM IR: Introducing a byte 
> type to solve load type punning" was accepted for GSoC 2021. My project 
> is about resolving an issue when optimizations introduce an implicit 
> `ptrtoint` instruction to load a pointer as an integer, breaking alias 
> analysis. My full proposal is here: 
> https://docs.google.com/document/d/1C6WLgoqoDJCTTSFGK01X8sR2sEccXV5JMabvTHlpOGE/edit?usp=sharing 
> <https://docs.google.com/document/d/1C6WLgoqoDJCTTSFGK01X8sR2sEccXV5JMabvTHlpOGE/edit?usp=sharing>.
> 
> I am looking forward to working with my mentors Nuno Lopes and Juneyoung 
> Lee, as well as excited about contributing to the LLVM community.
> 
> Thanks,
> George
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>