[llvm-commits] [LLVMdev] [RFC] "noclone" function attribute

[Kuperstein, Michael M]

I agree with Chris that we are not trying to express a "barrier" attribute, but a generic "noduplicate" attribute. Barriers have other properties which are not expressed by "noduplicate", and are completely outside the scope of this proposal.

However, I disagree on whether transitivity should be a part of the "noduplicate" property.
What we are trying to do here is to define useful semantics for "noduplicate". The motivation for introducing this attribute is to allow IR producers to signal to standard LLVM passes that some barrier-like function is used, so those passes won't break code that calls this function. This means the definition of "noduplicate" needs to be strictly stronger than what barrier-like constructs require in terms of duplication - for any reading of the (ambiguous) OpenCL spec. Part of this "strictly stronger" requirement is transitivity, since a module that has a non-"noduplicate" caller to a "noduplicate" callee can still be easily broken (w.r.t worst-case assumptions on barrier behavior) by standard passes even if the rest of this patch goes in.

Having the Verifier check transitivity achieves two goals:
1) It makes sure IR producers are not allowed to produce "breakable" code.
2) It makes sure transforming the IR cannot introduce "breakable" code. E.g. consider a pass that performs outlining of a piece of code that contains a noduplicate call, but does not mark the new function noduplicate.

I agree that (2) creates problems for devirtualization, but I would argue that code with an indirect call to a possibly-noduplicate function (where the callsite itself was not marked noduplicate) was broken to begin with, and the fact we catch it after devirtualization is a good thing.

In any case, it's not that this patch is bad without transitivity. I support it in any case, I'm just saying it would be more useful with the transitive semantics. 

Michael

-----Original Message-----
From: Chris Lattner [mailto:clattner at apple.com] 
Sent: Saturday, December 15, 2012 01:18
To: James Molloy
Cc: Dmitri Gribenko; llvm-commits; Kuperstein, Michael M
Subject: Re: [llvm-commits] [LLVMdev] [RFC] "noclone" function attribute

On Dec 14, 2012, at 9:40 AM, James Molloy <James.Molloy at arm.com> wrote:
> Hi Chris,
> 
> Thanks for the review. Replying now instead of with an updated patch 
> as I won't be able to get around to it until Monday.

Ok, no problem.

>> +        Assert1((*I)->cannotDuplicate(), "All functions which may transitively call a "
>> +                "noduplicate function must themselves be 
>> + noduplicate!", &F);
>> 
>> This doesn't make a lot of sense to me to enforce.  Can you explain the intuition for this limitation?  In practice, this will be difficult to handle, because devirtualization (and other things) can turn an indirect call to a direct call... if that direct call has the wrong noduplicate sense, we will get bad things happening.
> 
> I can try. It all comes down to the reading of the spec and the spirit 
> of the spec, and "ambiguous" is a kind way to describe it...

This is what I was afraid of.  We're discussing here the semantics of "noduplicate", not the semantics of barrier.  "noduplicate" semantics are a big part of what it means to be a barrier, but barriers may have additional requirements on top of it.

The LLVM "noduplicate" concept is independent of barrier, and should not have this transitive property.

-Chris


---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.