similar to: [LLVMdev] Is there any known bug related to NoDuplicate in LLVM/Clang 3.5

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

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

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 better and more accurately captures the real restriction. Is anyone still using noduplicate or really needs the semantics of noduplicate? There are a number of passes that now respect convergent, but do not try to

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

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,

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

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

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

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

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

Using LLVM ToT and Hal's helpful slide deck [1], I've been trying to use `llvm.assume` to communicate pointer alignment guarantees to vector load and store instructions. For example, in [2] %5 and %9 are guaranteed to be 32-byte aligned. However, if I run this IR through `opt -O3 -datalayout -S`, the vectorized loads and stores are still 1-byte aligned [3]. What's going wrong? Do I

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 function that ensures that all workitems executing a kernel have executed up to that point before execution on any workitem can

On Wed, Jun 21, 2017 at 05:25:04PM -0700, Mehdi AMINI via llvm-dev wrote: > Hi Kuba, > > Try: > > __attribute__(optnone) > > See > https://clang.llvm.org/docs/AttributeReference.html#optnone-clang-optnone Actually, it should be enough to use: __attribute__((noinline)) void please_do_not_optimize_me_away(int arg1, void *arg2) { asm