similar to: [LLVMdev] [RFC] "noclone" function attribute

I definitely support this. In fact we were about to send a very similar proposal. The main difference I can see between this proposal and ours was that we named the attribute "noduplicate". I graciously defer to James on the bikeshade color issue. Michael -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of James Molloy

Hi Krzysztof, Yes, however this can be solved in one of two ways: 1) Fully inline the call graph for all leaf functions that call the barrier intrinsic. This is done on several implementations as standard already, and "no call stack" is a requirement for Karrenberg's algorithm at least. 2) Apply the "noclone" attribute transitively such that if a function may

On 12/1/2012 10:02 AM, James Molloy wrote: > > This means that cloning whole functions (CloneFunction and CloneFunctionInto) will still work [...]. Unfortunately, it won't work. Assume all threads call foo: foo() { ... bar(i) ... } bar(int i) { ... barrier(); ... } Now, suppose that we have discovered that bar(0) can be greatly optimized and generate a call to

On 12/1/2012 10:02 AM, James Molloy wrote: > > I'm proposing a new function attribute, "noclone", with the semantics that "calls to functions marked "noclone" cannot be cloned or duplicated into the same function.". That is, it is illegal to call J = I->clone() then attach J to the same basic block as I if I is marked "noclone". The class Loop

Sounds good to me. I'm not sure the solution for transitivity is optimal, but it's a good compromise. -----Original Message----- From: James Molloy [mailto:James.Molloy at arm.com] Sent: Thursday, December 06, 2012 13:05 To: Kuperstein, Michael M Cc: Chris Lattner; llvm-commits; Nadav Rotem; llvmdev at cs.uiuc.edu Subject: RE: [LLVMdev] [RFC] "noclone" function attribute Hi

> Maybe a similar interface could be added to Instruction, and an > instruction would declare itself unsafe to clone if it was a call to a > function with the attribute that you are proposing. I experimented with something similar to this, where Instruction::clone ensured it wasn't "noclone" - if it was, it asserted. But that broke the use-case of cloning whole functions.

Hi Michael, After some head-scratching and discussion with our tame Khronos member, I agree with you. It comes down to the interpretation of the ambiguous spec. It refers to "the barrier", implying there is some sort of equivalence relation over barriers. The question is, what is that equivalent relation? In your example code: > void f(int foo) { > if (foo) > b();

I'm not sure I agree with the semantics this patch creates. The way I see it, there are two options: 1) Make "noduplicate" non-transitive and forbid inlining when there are multiple callsites. 2) Allow inlining, but make the attribute transitive. Consider the following code, where barrier() is marked noduplicate. kernel void k() { if (x()) y(); b(); if (x()) z();

On 12/1/2012 10:36 AM, James Molloy wrote: > > Either of these methods allow the user to stop LLVM "breaking their IR. I'm aware that the general case with no user help (such as force-inlining, or otherwise controlling function cloning) is a very difficult problem. My intention is that there are no corner cases *with user assistance*. Currently there is no way to stop stuff breaking

Hi all + llvm-commits, After the discussion below, please find attached my patch to add a new "noduplicate" function attribute. I've modified CodeMetrics and LoopInfo, which covers most cases, but JumpThreading and InlineCost don't use CodeMetrics yet, so they required changing manually. Cheers, James On Mon, 2012-12-03 at 23:46 +0000, Chris Lattner wrote: > On Dec 3,

Hi, Thanks for the pointers. My patch now calls the attribute "noduplicate", and updates CodeMetrics to have another field: bool notDuplicatable; Which semantically is "containsIndirectBr || containsNoDuplicateInst". I didn't repurpose containsIndirectBr because I felt what I'm looking for is sufficiently different (indirectbr inhibits inlining, whereas noduplicate

On Dec 3, 2012, at 9:48 AM, James Molloy <James.Molloy at arm.com> wrote: > Hi, > > Thanks for the pointers. My patch now calls the attribute "noduplicate", > and updates CodeMetrics to have another field: > > bool notDuplicatable; > > Which semantically is "containsIndirectBr || containsNoDuplicateInst". I > didn't repurpose

On 12/1/2012 11:25 AM, James Molloy wrote: >> Maybe a similar interface could be added to Instruction, and an >> instruction would declare itself unsafe to clone if it was a call to a >> function with the attribute that you are proposing. > > I experimented with something similar to this, where Instruction::clone ensured it wasn't "noclone" - if it was, it

On Dec 1, 2012, at 11:49 PM, "Kuperstein, Michael M" <michael.m.kuperstein at intel.com> wrote: > I definitely support this. > > In fact we were about to send a very similar proposal. The main difference I can see between this proposal and ours was that we named the attribute "noduplicate". > I graciously defer to James on the bikeshade color issue. Yes,

On Dec 4, 2013, at 8:25 PM, Andrew Trick <atrick at apple.com> wrote: > > On Dec 4, 2013, at 5:19 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > >> On 12/04/2013 04:29 PM, Andrew Trick wrote: >>> On Dec 4, 2013, at 3:33 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote: >>> >>>> On 11/11/2013 03:13 PM, Andrew

On Dec 2, 2012, at 10:11 PM, Chris Lattner <clattner at apple.com> wrote: > 3) Please change random parts of the compiler to use CodeMetrics, instead of scattering random checks for this attribute throughout the code. Anything duplicating code and not using CodeMetrics is just plain incorrect. One problem that we may run into when using CodeMetrics is compile time. In many cases we

On Nov 9, 2013, at 3:14 AM, Chandler Carruth <chandlerc at google.com> wrote: > > Perhaps you're instead trying to say that with certain address spaces "noalias" (and by inference, "restrict" at the language level) has a different semantic model than other address spaces? While it's less worrisome than the first interpretation, I still don't really

On Nov 9, 2013, at 1:39 PM, Matt Arsenault <arsenm2 at gmail.com> wrote: > On Nov 9, 2013, at 3:14 AM, Chandler Carruth <chandlerc at google.com> wrote: > >> >> Perhaps you're instead trying to say that with certain address spaces "noalias" (and by inference, "restrict" at the language level) has a different semantic model than other address

On Dec 4, 2013, at 5:19 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > On 12/04/2013 04:29 PM, Andrew Trick wrote: >> On Dec 4, 2013, at 3:33 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote: >> >>> On 11/11/2013 03:13 PM, Andrew Trick wrote: >>>> On Nov 9, 2013, at 1:39 PM, Matt Arsenault <arsenm2 at gmail.com> wrote:

On 12/04/2013 04:29 PM, Andrew Trick wrote: > On Dec 4, 2013, at 3:33 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > >> On 11/11/2013 03:13 PM, Andrew Trick wrote: >>> On Nov 9, 2013, at 1:39 PM, Matt Arsenault <arsenm2 at gmail.com> wrote: >>> >>>> On Nov 9, 2013, at 3:14 AM, Chandler Carruth <chandlerc at google.com> wrote: