similar to: RFC: Removal of noduplicate attribute

On 10/27, Aaron Ballman via llvm-dev wrote: > On Fri, Oct 25, 2019 at 7:37 PM Arsenault, Matthew via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > Hi, > > > > Can the noduplicate attribute be deleted? It was originally added to > > satisfy the constraints of OpenCL barriers, but it didn’t really > > solve this problem. Convergent is strictly

On Tue, Oct 29, 2019 at 11:57 AM Savonichev, Andrew via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > These are good points. I think the first question should be: Do we know > > of any active users of this attribute right now? If not, deprecation > > seems like something we could do, e.g., through a warning in clang and > > in the middle-end to ensure other

Hello all, I have a question related to noduplicate attribute. For example, if I have the following source code: __attribute__((noduplicate)) __attribute__((always_inline)) void wait () { // some code barrier(); // some code } __attribute__((noduplicate)) void barrier (); void f () { // some code wait(); // some code } Sometimes I observed a phenomenon that

Hello James, Thanks for your reply. My apologies that I mark the function 'wait' with noduplicate in the above example. In fact I didn't use __attribute__((noduplicate)) with function 'wait' in my implementation so there is no bug in LLVM. I would dig up the original discussions between you and Chris Lattner for more context. Thanks. -------------- next part --------------

Hi Mehdi, My reading of it is that if you have a convergent instruction A, it is legal to duplicate it to instruction B if (assuming B is after A in program flow) A dominates B and B post-dominates A. James On Fri, 14 Aug 2015 at 08:32 Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Aug 13, 2015, at 9:43 PM, Owen Anderson via llvm-dev < > llvm-dev at

Hi Jingyue, Convergent is not intended to prevent inlining. It’s tricky to formalize this inter-procedurally, but the intended interpretation is that a convergent operation cannot be move either into or out of a conditionally executed region. Normal inlining would not violate that. I would imagine that it would make sense to use a combination of convergent and noduplicate for barrier-like

On Thu, Dec 26, 2013 at 8:54 PM, Andrew Trick <atrick at apple.com> wrote: > Others can weigh in here. This is just my understanding. Attribute > propagation has to be optional because we can’t assume inter-procedural > optimization runs for correct codegen. What if the memfence resides in a > different module? > > In the case of noduplicate, the only reason to propagate

Hello all, I am using LLVM/Clang 3.5 to build a C++ extension. Such C++ extension contains a special function named "barrier", which shouldn't be duplicated. So I add __attribute__((noduplicate)) on barrier declaration. For some reasons, I also add AlwaysInlineAttr attribute on each function except main function. The generated LLVM IR what I expect is only a main function with many

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 20.12.18 18:03, Connor Abbott wrote: > We already have the notion of "convergent" functions like > syncthreads(), to which we cannot add control-flow dependencies. > That is, it's legal to hoist syncthreads out of an "if", but it's > not legal to sink it into an "if".  It's not clear to me why we > can't have

I don't see how this would fix the continue vs. nested loop problem I explained earlier. That is, how would this prevent turning: for (...) { ballot(); if (... /* non-uniform */) continue; } into for (...) { do { ballot(); } while (... /* non-uniform */); } and vice versa? Note that there's no duplication going on here, and the single-threaded flow of control is

Below is a proposal for a new "convergent" intrinsic attribute and MachineInstr property, needed for correctly modeling many SPMD/SIMT programming models in LLVM. Comments and feedback welcome. —Owen In order to make LLVM more suitable for programming models variously called SPMD and SIMT, we would like to propose a new intrinsic and MachineInstr annotation called

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

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,

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();

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();

On Fri, Jan 25, 2019 at 3:05 AM Jan Sjodin <jan_sjodin at yahoo.com> wrote: > > > for (...) { > > ballot(); > > if (... /* non-uniform */) continue; > > } > > > > into > > > > for (...) { > > do { > > ballot(); > > } while (... /* non-uniform */); > > } > > I'm not sure if I follow

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

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