search for: noduplicate

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 } S...

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? Ther...

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 better and more > > accurately captures the real restriction. Is anyone still using > > noduplicate or really...

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 -------------- An HTML...

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 LLVM IRs. However when I counts the number of barrier function call of the output LLVM IR, I found the num...

...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 AFAICT would be > to suppress inlining. It seems reasonable enough to expect attribute > propagation to happen before inlining. So I don't think noduplicate is an > issue in practice. > I think you've misunderstood the specification of noduplicate....

...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 front-ends are aware of it as well. > > Noduplicate attribute is still used by the Intel OpenCL Compiler for CPU. > The main use case is to prevent loop unroll when an OpenCL barrier is called > within a loop. Although such loop can be unrolled and keep its semantic intact, but > this introduces a lot of distinct barrier calls, and each of...

...h the True condition is not the same as the barrier as reached through the False condition, even though it is the same statement as written in CL-C. So inlining should not be restricted, as you say. With regards transitivity, I'd say that it is the user's responsibility to ensure that the noduplicate attribute is transitively applied correctly before handing it to the optimizer. Otherwise, we'd need costly checks every time a user asks the question "is this function noduplicate?" So my proposed change is to remove the restrictions on inlining and update the LangRef to say that th...

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, 2012, at 9:48 A...

...h the True condition is not the same as the barrier as reached through the False condition, even though it is the same statement as written in CL-C. So inlining should not be restricted, as you say. With regards transitivity, I'd say that it is the user's responsibility to ensure that the noduplicate attribute is transitively applied correctly before handing it to the optimizer. Otherwise, we'd need costly checks every time a user asks the question "is this function noduplicate?" So my proposed change is to remove the restrictions on inlining and update the LangRef to say that th...

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(); else w(); } void b() { ba...

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

...ry function with at least 4 nomemfences, and remove them when encountering the memfence intrinsic. > > > Sure, but the program still needs to be correct if you skip attribute propagation. > -Andy Is this a requirement for an attribute? This would be a problem for the already existing noduplicate. If a function has a call to a noduplicate function, the calling function could still be duplicated if the attribute isn’t propagated which isn’t allowed. - Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments...

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 containsIndirectBr because I felt what I'm looking for > is sufficiently differe...

Hi, For a certain type of analysis I generate inline assembly which I insert into the LLVM IR code. This inline assembly code contains labels that should not be duplicated. Problem is that the tail duplication pass duplicates code. It checks isNotDuplicatable on a machine instruction however there is no such a flag on an IR instruction that I could set. Is there a way to tell in an IR pass that

...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, this sort of functionality is useful. A few requests though: 1) please name it "noduplicate". "cloning" has other naming implications in llvm related to function bodies, but calls to a noduplicate fun...

...ligned [3]. What's going wrong? Do I have to move the `llvm.assume` into the loop body? v/r, Josh [1] http://llvm.org/devmtg/2014-10/Slides/Finkel-IntrinsicsMetadataAttributes.pdf [2] ; ModuleID = 'align.ll' %u8XY = type { i32, i32, i32, i32, i32, i32, [0 x i8] } ; Function Attrs: noduplicate nounwind readonly declare noalias %u8XY* @likely_new(i32 zeroext, i32 zeroext, i32 zeroext, i32 zeroext, i32 zeroext, i8* noalias nocapture) #0 ; Function Attrs: nounwind declare void @llvm.assume(i1) #1 ; Function Attrs: nounwind define %u8XY* @benchmark(%u8XY*) #1 { entry: %1 = getelementptr...

...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 operations. —Owen > On Aug 13, 2015, at 3:12 PM, Jingyue Wu <jingyue at google.com> wrote: > > Hi Owen, > > According to your design, is LLVM supposed to (partially) disallow inlining a function that has convergent instructions? It's hard to define con...

...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 operations. > > > Isn’t convergent implying “noduplicate” inside a function? > It’s late but I’m not sure I can figure when a transformation would be > allowed to duplicate a call to a convergent intrinsic? > > — > Mehdi > > > > —Owen > > O...

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 Sent: Saturday, December 01, 2012 18:03 To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] [RFC] &...