similar to: [LLVMdev] llvm.memory.barrier does not work

On Wed, Sep 28, 2011 at 5:47 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Sep 28, 2011 at 3:27 PM, Junjie Gu <jgu222 at gmail.com> wrote: >> Instrinsic llvm.memory.barrier does not work as expected.  Is it a bug >> or it has not been implemented yet ? > > It's going away in favor of the new fence instruction (and I'll remove > it as soon

On Wed, Sep 28, 2011 at 3:27 PM, Junjie Gu <jgu222 at gmail.com> wrote: > Instrinsic llvm.memory.barrier does not work as expected.  Is it a bug > or it has not been implemented yet ? It's going away in favor of the new fence instruction (and I'll remove it as soon as dragonegg catches up). It should still work at the moment, though. > (1) false arguments do not work >

On Tue, Jun 1, 2010 at 5:42 PM, Junjie Gu <jgu222 at gmail.com> wrote: > Any suggestions/ideas ? IIUC, Chris suggested something like following ... header: br i1 %x, label %then, %label endif then: ... br i1 %y, label %loop_exit, label %header, !loop_pragma !1 endif: ... br i1 %z, label %loop_exit, label %header, !loop_pragma !2 loop_exit: ret i32 1 Where !1 and !2 are the

Thanks for comments/suggestions. Yes, attaching metadata to instructions will be good choices for many cases. But for loops, attaching metadata to back-edges requires that the front end to build loops, which is an additional task for the front end. And this task is really a backend's job, not the front end's. If the only concern is that it is hard for pragma intrinsics to stay with their

Hi, For a long time we've been having a problem we've been working around in OpenCL where loads are moving across an intrinsic used for a barrier. Attached is the testcase, and the result of opt -S -basicaa -gvn on it. This example is essentially this: void foo(global float2* result, local float2* restrict data0, ...) { int id = get_local_id(0); // ... data0[id] = ...;

Hi Chris, Thanks. I will see what I can do for this. Junjie On Wed, May 19, 2010 at 3:45 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 19, 2010, at 2:38 PM, Junjie Gu wrote: > >> Many compilers support per-loop pragma, such as loop unrolling (ie >> #pragma unroll=2).  Is there any LLVM project/effort going on >> in this area ? What is the expected

I'd like to add a pragma support in llvm. I am thinking about using a llvm intrinsic to represent each pragma, such as llvm.pragma (metadata, ...) where metadata describes a pragma. So if an application has: #pragma p1 .. #pragma p2... for (...) The llvm IR would be llvm.pragma (metadata..) // for p1 llvm.pragma (metadata..) // for p2 llvm IR for "for

When I request a write-before-read memory barrier on x86 I would expect to get an assembly instruction that would enforce this ordering (mfence, xchg, cas), but it just turns into a nop. 1. ; ModuleID = 'test.bc' 2. target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32- i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:128:128" 3. target

Thanks for the info. My impression is that __sync_synchronize takes no arguments and is the memory barrier, i.e., "llvm.memory.barrier(i1 true,i1 true,i1 true,i1 true,i1 true)". Is that right? I would like a little finer control to express just a write barrier (st-st) or a read barrier. -- Mon Ping On Sep 17, 2008, at 5:50 AM, Andrew Lenharth wrote: > On Tue, Sep 16,

Mon Ping Wang wrote: > Thanks for the info. My impression is that __sync_synchronize takes > no arguments and is the memory barrier, i.e., > "llvm.memory.barrier(i1 true,i1 true,i1 true,i1 true,i1 true)". Is > that right? That's my understanding as well. > I would like a little finer control to express just a > write barrier (st-st) or a read barrier.

Hi Luke, What you say makes sense but I'm not sure it is a good way to go. If we are using a gcc function name __sync_synchronize, I generally feel like we should support it with exactly the same signature and not try to extend it. Otherwise, it might lead to some confusion in the future unless they also plan to extend it the same way. -- Mon Ping On Sep 17, 2008, at 1:14 PM,

On Tue, Sep 16, 2008 at 11:22 PM, Duncan Sands <baldrick at free.fr> wrote: >> I would like access to LLVM memory barrier instruction as a built-in >> from clang, which means that I need a name for it. In gcc, I see names >> like __builtin_ia32_mfence but those refers to X86 SSE instruction >> that we support. I don't see a gcc name that has the same semantics

If LLVM would like to support OpenMP pragma in the future, not sure if attaching metadata to instructions is still a good choice. Junjie On Wed, Jun 2, 2010 at 11:08 AM, Junjie Gu <jgu222 at gmail.com> wrote: > Thanks for comments/suggestions. > > Yes, attaching metadata to instructions will be good choices for many > cases. But for loops, > attaching metadata to back-edges

The scoreboard hazard detector that I've added for the PPC 440 is not detecting hazards as it should (which certainly could be my fault somehow, but...). For example, it will produce a schedule that looks like... SU(28): 0x127969b0: f64,ch = LFD 0x12793aa0, 0x1277b4f0, 0x127965b0<Mem:LD8[%scevgep100](tbaa=!"double")> [ORD=41] [ID=28] SU(46): 0x12796ab0: f64 = FADD 0x127969b0,

Given a pointer, does any addrspacecast affect the pointer's dereferenceablity ? For example, %pm = addrspaacecast float addrspacecast(n)* %pn to float addrspacecast(m)* %r = load float addrspace(m)* %pm In another word. the question is whether the following is true ? isDereferenceablePointer(pn) == isDereferenceablePointer(pm) [Note that the function is defined as

Thanks for your point that out. I just add DataLayout in my code such as "mod->setDataLayout("e-m:e-i64:64-f80:128-n8:16:32:64-S128");", still no luck. I'm really confused about this. Do I need to add more passes before -loop-unroll? On Sat, Aug 22, 2015 at 11:36 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Aug 22, 2015, at 7:27 AM, Xiangyang

Hi, Mehdi, For example, I have this very simple source code: void foo( int n, int array_x[]) { for (int i=0; i < n; i++) array_x[i] = i; } After I use "clang -emit-llvm -o bc_from_clang.bc -c try.cc", I get bc_from_clang.bc. With my code (using LLVM IRbuilder API), I get bc_from_api.bc. Attachment please find thse two files. I also past the IR here.

On Wed, Jun 2, 2010 at 11:08 AM, Junjie Gu <jgu222 at gmail.com> wrote: > Thanks for comments/suggestions. > > Yes, attaching metadata to instructions will be good choices for many > cases. But for loops, > attaching metadata to back-edges requires that the front end to build > loops, which is an > additional task for the front end. And this task is really a

On some targets with limited addressing modes, getting that 64-bit relocatable but loop-invariant value into a register requires several instructions. I'd like those several instruction outside the loop, where they belong. Yes, my experience is that something (I assume instcombine) recanonicalizes. Thanks, Preston On Tue, Dec 8, 2015 at 11:21 PM, Mehdi Amini <mehdi.amini at

Guess I have found some clues. Some necessary libraries have to be loaded while trying to generate native code or do interpretation. Then another question emerges: Is there a way to determine the necessary libraries in need? And where to locate these necessary libraries? Xiaolong > Hi All, > > I have a program that uses C++ STL a lot. To have the source code for > STL functions, I