search for: noclon

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

...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. My patch extends Loop::isSafeToClone to check if a callinst is contained which is "noclone". I agree about the naming, but have yet to think of something more snappy :) Cheers, James _____________...

...cloned. This can happen in loop unrolling, loop unswitching and jump threading, currently. I believe multiple CL vendors have hacked ad-hoc checking in these three areas currently - it'd be nice to standardise this and reduce downstream hacks. 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". This means that cloning...

...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. I guess the problem would be when the compiler wants to clone the instruction with the plan of deleting the original later. In such a scenario there could be temporarily (and legitimately) multiple calls to...

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

...;. 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 Sent: Saturday, December 01, 2012 18:03 To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] [RFC] "noclone" function attribute Hi, OpenCL has a "barrier" function with very specific semantics, and there is currently no analogue to model this in LLVM. This has been touched on by the SPIR folks but I don't believe they put forward a proposal. The barrier function is a special funct...

...ver 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 transitively call the barrier intrinsic, it is marked "noclone". 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 otherw...

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

On Sun, Dec 2, 2012 at 10:27 PM, Nadav Rotem <nrotem at apple.com> wrote: > > 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

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

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

...no inlining" approach that the patch takes. -----Original Message----- From: James Molloy [mailto:James.Molloy at arm.com] Sent: Tuesday, December 04, 2012 19:23 To: Chris Lattner; llvm-commits Cc: Nadav Rotem; Kuperstein, Michael M; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] [RFC] "noclone" function attribute 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,...

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,

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,

...the patch takes. > > -----Original Message----- > From: James Molloy [mailto:James.Molloy at arm.com] > Sent: Tuesday, December 04, 2012 19:23 > To: Chris Lattner; llvm-commits > Cc: Nadav Rotem; Kuperstein, Michael M; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] [RFC] "noclone" function attribute > > 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...

...llvm.memory.barrier(...); ------------------ We're doing C to HDL compilation with LLVM. Having multiple locations that call llvm.memory.barrier(...) would cause complications to generated hardware. So far, I can think of only two solutions. One is to add support for something like "noclone" attribute and update all optimizations to obey it. The other is to re-merge the calls as a final pass. Any better ideas? Thank you, Dmitry ________________________________ Confidentiality Notice. This message may contain information that is confidential or otherwise protected from disclos...

...----- > > > > We’re doing C to HDL compilation with LLVM. Having multiple locations that > call llvm.memory.barrier(...) would cause complications to generated > hardware. > > > > So far, I can think of only two solutions. One is to add support for > something like “noclone” attribute and update all optimizations to obey it. > The other is to re-merge the calls as a final pass. Any better ideas? > > > > Thank you, > > Dmitry > > > > ________________________________ > Confidentiality Notice. > This message may contain information...

...----- > > > > We’re doing C to HDL compilation with LLVM. Having multiple locations that > call llvm.memory.barrier(...) would cause complications to generated > hardware. > > > > So far, I can think of only two solutions. One is to add support for > something like “noclone” attribute and update all optimizations to obey it. > The other is to re-merge the calls as a final pass. Any better ideas? > > > > Thank you, > > Dmitry > > > > ________________________________ > Confidentiality Notice. > This message may contain information...