[LLVMdev] Proposal for safe-to-execute meta-data for heap accesses

Filip Pizlo fpizlo at apple.com
Fri Nov 8 08:44:21 PST 2013



> On Nov 8, 2013, at 1:13 AM, Chandler Carruth <chandlerc at google.com> wrote:
> 
> 
>> On Thu, Nov 7, 2013 at 9:39 PM, Filip Pizlo <fpizlo at apple.com> wrote:
>> NEW PROPOSAL
>> 
>> The solution is to introduce meta-data that is explicit about how the safe-to-execute condition ought to be evaluated.  Instead of an SSA use, we can have meta-data that says:
>> 
>>         %v = load %p !notrap !{ @f, <args> }
>> 
>> where @f is a function in the current module and this function returns i1, and <args> is zero or more arguments to pass to @f.  As with any meta-data, this doesn’t imply anything different if you wanted to just execute the code: executing the load doesn’t imply calling @f; indeed if you dropped the meta-data the execution of this would still be the same.
> 
> So, first a clarifying question:
> 
> Is the expectation that to utilize this metadata an optimization pass would have to inspect the body of @f and reason about its behavior given <args>?

Yes. 

> 
> If so, then I think this is pretty bad. If we ever want to parallelize function passes, then they can't inspect the innards of other functions.

I must be missing something. Can't you do some simple locking?  Lock a function if it's being transformed, or if you want to inspect it...

> So this would significantly constrain the utility here.

I think we can engineer around this problem. For example, the function @f is meant to contain basically hand-written IR; it ought not be necessary to optimize it in order to make use of it for safe-to-execute. It's also reasonable to expect these to be small. 

Hence you can imagine freezing a copy of those functions that are used in this meta-data. 

> 
> Also, this would create uses of the arguments that were "ephemeral" uses.

I think they're ephemeral in a very different sense than the previous !notrap; for example here the used continue to be meaningful even after replaceAllUsesWith. 

> It's not clear how that is better than any of the other proposals to represent constraint systems in the IR via "ephemeral" uses.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131108/9d2038f0/attachment.html>


More information about the llvm-dev mailing list