search for: 053798

...th some work. Ideally, I'd like to have a different class (ParallelLoop, maybe) altogether representing parallel loops and make the relevant passes aware of it. More work, yes, but I think such an approach will pay off eventually. [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/053798.html -- Sanjoy Das http://playingwithpointers.com

...to read it. As with this proposal, I fear any direct parallelization support in LLVM is going to take us out of the "low level" feature of LLVM which is a huge strength. > and the other, based somewhat on mine, by Sanjoy > (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/053798.html) I read this proposal quickly. I don't understand why we need intrinsics. Won't calls to runtime routines work just fine? Ah, Sanjoy had a link to your proposal in his message. Again, I only skimmed the document, but I was left with the question, "why not just make calls to r...

...the reply! > As you may know, this is the third such proposal over the past two > months, one by me > (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-August/052472.html) > and the other, based somewhat on mine, by Sanjoy > (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/053798.html) Yes, I was aware of your proposal. I hesitated to make any comments or criticism -- as I am, obviously, biased. In my opinion, two most important differences between our proposals are: 1) Your design employs explicit procedurization done in front-end, while our design allows both early (ri...

...altogether representing parallel loops and make > the relevant passes aware of it. More work, yes, but I think such an > approach will pay off eventually. Can you be more specific? Pay off how? Thanks again, Hal > > [1] > http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/053798.html -- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory

...his proposal, I fear any direct > parallelization support in LLVM is going to take us out of the "low > level" feature of LLVM which is a huge strength. > >> and the other, based somewhat on mine, by Sanjoy >> (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/053798.html) > > I read this proposal quickly. I don't understand why we need > intrinsics. Won't calls to runtime routines work just fine? > > Ah, Sanjoy had a link to your proposal in his message. > > Again, I only skimmed the document, but I was left with the question, &g...

...king on this! I have a few comments: As you may know, this is the third such proposal over the past two months, one by me (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-August/052472.html) and the other, based somewhat on mine, by Sanjoy (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/053798.html) In order for your proposal to work well, there will be a lot of infrastructure work required (more than with my proposal); many passes will need to be made explicitly aware of how they can, or can't, reorder things with respect to the parallelization intrinsics; loop restructuring may re...

Hal, Andrey, Alexey, >From the LLVM design viewpoint, there is a fundamental problem with both Hal's approach and the Intel approach: both are quite language-specific. OpenMP is a particular parallel language, with particular constructs (e.g., parallel regions) and semantics. LLVM is a language-neutral IR and infrastructure and OpenMP-specific concepts should not creep into it. I've

Hi All, We'd like to make a proposal for OpenMP representation in LLVM IR. Our goal is to reach an agreement in the community on a simple, complete and extensible representation of OpenMP language constructs in LLVM IR. Hopefully, this would serve as a common ground and would enable further development of OpenMP support both in Clang and LLVM compiler toolchain. We seek feedback on the