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

[Kuperstein, Michael M]

I didn't mean to imply that you don't know what the advantages of the verifier are, I apologize if it came off this way. 

In any case, if there is consensus transitivity is not a desirable property, I certainly won't oppose it. 
Dropping the issue, thanks for all the insightful comments.

Michael

-----Original Message-----
From: Chris Lattner [mailto:clattner at apple.com] 
Sent: Sunday, December 16, 2012 23:55
To: Kuperstein, Michael M
Cc: James Molloy; Dmitri Gribenko; llvm-commits; Aboud, Amjad; Zaks, Ayal
Subject: Re: [llvm-commits] [LLVMdev] [RFC] "noclone" function attribute


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

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