similar to: [LLVMdev] Support for per-loop pragma

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

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 way for implementing per-loop > pragma, or general pragma ? Suggestions/comments ? Hi Junjie, I don't know of anyone working on it, but it seems like a natural

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

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

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

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

Thanks for the explanation. But I am a little confused with the following fact. Can't LLVM keep vectorizable_elements as a symbolic value and convert the loop to say; for(unsigned i = 0; i < vectorizable_elements ; i += 2){ //main loop } for(unsigned i=0 ; i < vectorizable_elements % 2; i++){ //fix up } Why does it have to reason about the range of vectorizable_elements? Even

If count > MAX_UINT-4 your loop loops indefinitely with an increment of 4, I think. On Thu, Oct 13, 2016 at 4:42 PM, Charith Mendis via llvm-dev < llvm-dev at lists.llvm.org> wrote: > So, I tried unrolling the following simple loop. > > int unroll(unsigned * a, unsigned * b, unsigned *c, unsigned count){ > > for(unsigned i=0; i<count; i++){ > > a[i] =

Hi, all. I want to give programmer ability to tell LLVM that certain region of code is expected to get specialized optimization. So, I'm trying to make custom pragma to mark certain region of code and pass this information to LLVM, in the similar way that '#pragma clang loop unroll_count(N)' works. By tracking the framework of loop unroll pragma, I found out it works in the way below.

Yes. I checked that file, but I wasn't sure whether that is right one to look at. What is *.td extension btw? When I google it, it says this is for Windows Debug Simulator. Why clang use this extension, which is limited to Windows environment? On Tue, Oct 25, 2016 at 7:00 PM, Vedant Kumar <vsk at apple.com> wrote: > That file is generated by the clang-tblgen tool: > >

> Yes. I checked that file, but I wasn't sure whether that is right one to look at. It seems promising. I imagine you'd want something like the LoopHint attr. > What is *.td extension btw? The llvm project uses that extension to identify TableGen inputs (http://llvm.org/docs/TableGen/). vedant > On Oct 25, 2016, at 4:12 PM, Sunghyun Park <sunggg at umich.edu> wrote:

Hi all, Attached herewith is a simple vectorized function with loops performing a simple shuffle. I want all loops (inner and outer) to be unrolled by 2 and as such used -unroll-count=2 The inner loops(with k as the induction variable and having constant trip counts) unroll fully, but the outer loop with (j) fails to unroll. The llvm code is also attached with inner loops fully unrolled. To

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

I'd like to add a custom #pragma directive in clang for research purposes. I'm familiar with the LLVM pass-writing interface but new to the rest of LLVM and clang. I've looked into Simone Pellegrini's work on a #pragma interface (https://github.com/motonacciu/clomp and http://llvm.org/devmtg/2013-04/pellegrini-slides.pdf), but I'm in no position to determine if this approach

Hi everyone, I wanted to assign a new pragma for loops in clang. Let's call it "#pragma XXX" which can be applied to any loop in the entire loop hierarchy. I added the support for my pragma by following the same steps as were being used in the default implementation of "unroll" pragma. But now, when I compile any program using clang to llvm IR it attaches the pragma

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

Is it OK to remove metadata in an optimization pass? The context is patch http://reviews.llvm.org/D4571 which removes loop unrolling hint metadata after using it to avoid unrolling more than the hint suggests. This is a potential problem because loop unrolling can be run more than once. Example: a loop annotated with "#pragma clang loop unroll_count(2)" which adds hint metadata to the

Skipping the clang question for now, this had to be a loop pragma of some kind. One step back: what we really need is a way to express that memory accesses between iterations can be re-ordered. The code that's being compiled _is_ noalias, but we don't _have_ to use noalias semantics, e.g. loop parallel semantics are sufficient. What's missing is a way to express that past the llvm

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 >