jmciver added a comment.

@nikic as per my GSoC project I am trying, under the guidance of @nlopes, a 
load attribute based approach to migrating uninitialized load to poison. The 
first attribute that I am working on is !freeze which effectively inserts a 
freeze poison if the load is uninitialized. Obviously this can only be done in
optimizations that allow instruction creation. In the future I am looking to 
add a load instruction parameter to getInitialValueOfAllocation to allow 
modification of the returned constant based on the allocation 
function/instruction and the presence of a load attribute.

So why pack the alloca test into getInitialValueOfAllocation? The reasoning is 
that attribute is on a per-load instruction, but allocation could be alloca or 
function. I agree if the application of the load attribute were universal 
passing in the default value to mem2reg would work, but as we are modulating 
the returned constant based on individual load instruction attributes this 
would not work. Hence the query based approach.

As for the TLI I agree that making it required is probably not ideal. @nlopes 
can vouch that I thought about this :-). Two options off the top of my head are:

1. Make the TLI parameter of getInitialValueOfAllocation a pointer with 
defaults to nullptr.

2. Add a separated query function for alloca instructions.

The advantage to option 1 is all allocation initial state queries are handled 
in one place. The detractor is we have a parameter that has a default nullptr.

The advantage to option 2 is allocation functions vs alloca instruction are 
handled by functions that have only the required parameterizations exposed. The 
detractor is there will be some combinatorial overlap between the two functions.

Thoughts?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D155773/new/

https://reviews.llvm.org/D155773

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to