search for: jgu222

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

...optimizer and associates them to instructions by either attaching metadata to instructions and some kind maps (between instructions/BB to metadata, etc). Junjie On Wed, Jun 2, 2010 at 9:48 AM, Devang Patel <devang.patel at gmail.com> wrote: > 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 %...

...equency hint for a branch, etc). And it should be easy for any frontend to generate. A possible issue might be that optimizations might make the association between pragmas and their loops (in this case) less obvious. Any suggestions/ideas ? Junjie On Wed, May 19, 2010 at 4:31 PM, Junjie Gu <jgu222 at gmail.com> wrote: > 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 compi...

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

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 as dragonegg catches up).  It should still w...

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 requires that the front end to build > loops, which is an > additional task for the fr...

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

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

Instrinsic llvm.memory.barrier does not work as expected. Is it a bug or it has not been implemented yet ? (1) false arguments do not work // pesudo code void foo(int *x) { x[2] = 10; llvm.memory.barrier(0, 0, 0, 0, 0); x[2] = 20; return void } The barrier is actually noop, but it prevents "x[2] = 10" from being deleted. (2) True arguments do not work. // pesudo code

On 17 Mar 2015, at 20:06, Junjie Gu <jgu222 at gmail.com> wrote: >> I've just been debugging a related issue with regard to commutativity of address space casts with respect to other operations. One of the optimisers is turning an add after an address space cast into an add before the address space cast. On our architecture,...

I am trying to add an analysis pass as a FunctionPass, and let LICM (LoopPass) depends upon it. So in LICM.cpp, I have the following: virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesCFG(); AU.addRequired<DominatorTree>(); AU.addRequired<LoopInfo>(); AU.addRequiredID(LoopSimplifyID); AU.addRequired<AliasAnalysis>();

On 16 Mar 2015, at 08:25, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > The LangRef says this about addrspacecast: "Note that if the address > space conversion is legal then both result and operand refer to the > same memory location.". This brings forth two related questions: > > 1. what happens if you execute an "invalid" addrspacecast?

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

Hello, LoopSimplify try to separate a loop with multiple backedges into a nested loop (an outer loop and an inner loop). Naturally, this kind of a loop corresponds to a single loop in source code. I can see this could be useful for cases described in the comments in lib/Transforms/Utils/LoopSimplify.cpp, which looks like a corner case. For most cases, how does this help ? Junjie

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 way for implementing per-loop pragma, or general pragma ? Suggestions/comments ? Thanks Junjie

I have a MDNode, and one of its operand is an int. I'd like to assign a new int value to that operand during the llvm optimization. What is the right way to do this ? (There is no setOperand() with MDNode class.) Junjie

Suppose I have a multi-threaded application that needs to compile many independant bitcodes. All threads do compilation concurrently. For each thread, it creates its own context like the following: LLVMContext *mycontext = new LLVMContext(); But it seems there are still places that explicitly refer to the global context (like in Module.cpp). I wonder wether this is indended or has yet to be

I have TOT of llvm and it builds 64-bit without issues on my 64-bit ubuntu. My question is how to build 32-bit llvm on my 64-bit ubuntu ? I've not found any configure options to specify that. Thanks Junjie

On Fri, Mar 4, 2011 at 12:38 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Junjie, > >> I have TOT of llvm and it builds 64-bit without issues on my 64-bit >> ubuntu.  My question is how to build 32-bit llvm on my 64-bit ubuntu ? >> I've not found any configure options to specify that. > > as well as "gcc -m32" and "g++ -m32" you may

I tried a simple float math (a + b - b) using llc's option –enable-unsafe-fp-math, but I still have add and sub in the code (x86). Does LLVM perform any float/double reassociation, etc under unsafe math or fast-math ? Thanks Junjie