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

[James Molloy]

Hi Chris,

After a 1-day haitus, attaching a new patch.

The new patch is based upon my first patch, which had the semantics you
wanted. I've addressed all your code review points, I hope.

I couldn't move CloneBasicBlock completely to use CodeMetrics, because
it needs some stuff that isn't checked by CodeMetrics (number of static
allocas and the number of calls*).

If you'd prefer I could add those to CodeMetrics so the whole thing
could be ported over?

Merry Christmas,

James

*: CodeMetrics has a member "numCalls" which gives the number of "small"
calls - clients of CloneBasicBlock need to know the number of IR-level
call instructions, I believe, and these are not the same thing.

On Tue, 2012-12-18 at 19:19 +0000, Chris Lattner wrote:
> On Dec 16, 2012, at 11:37 PM, "Kuperstein, Michael M" <michael.m.kuperstein at intel.com> wrote:
>
> > 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.
>
> I think I should have added a ":)" to that, I didn't mean it to come across as snippy!  Sorry for that,
>
> -Chris
>
>
> >
> > 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.
> >
>
>
>


-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: noduplicate.diff
Type: text/x-patch
Size: 24311 bytes
Desc: noduplicate.diff
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121219/e5b731d1/attachment.bin>