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

Chris Lattner clattner at apple.com
Sun Dec 16 13:54:47 PST 2012


On Dec 15, 2012, at 3:19 AM, "Kuperstein, Michael M" <michael.m.kuperstein at intel.com> wrote:

> 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.

Right.

> 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".

Right.

> 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.

Wait, again, what does noduplicate have to do with barriers?  Please stop talking about noduplicate as a solution to barriers, we should define the semantics of noduplicate on its own.

As a non-barrier example of something that could use "noduplicate", consider an inline assembly blob that contains a label in it.  At most one instance of this inline asm blob can be emitted to .s file for the translation unit, and this sort of thing seems like the perfect application of noduplicate.

> 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.

Again, you've gone off the rails here, by trying to make noduplicate OpenCL specific.

> 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'm familiar with the advantages of having the verifier check invariants, I'm arguing that this is not an invariant that makes sense for noduplicate.

-Chris




More information about the llvm-commits mailing list