greened at obbligato.org
2012-Oct-02 01:15 UTC
[LLVMdev] [RFC] OpenMP Representation in LLVM IR
Hal Finkel <hfinkel at anl.gov> writes: Hi Hal,> 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)This link seems to be broken. I missed your earlier proposal and would like 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 runtime routines?" What is the reason for the "paralleliation metadata?" It seems to me this implies/requires that LLVM have knowledge of parallel semantics. That would be very unfortunate. -David
Hi David, Thank you for your comments. Basically, I agree with Hal's answers -- nothing substantial to add to what he already said. As for> Again, I only skimmed the document, but I was left with the question, > "why not just make calls to runtime routines?"Granted, this is the easiest and cheapest way to support OpenMP... that throws away the whole notion of "optimizing compilation" and "front-end / back-end decoupling". Using same logic: why bother with virtual registers? Why not to use target machine's physical registers in IR code generated by a front-end? Right? Wait a sec... LLVM IR is meant to be portable and supporting "life-long program analysis and transformation". Locking it with target machine's OpenMP runtime calls from the very beginning is not the best way to acheive these goals. Same with physical registers -- this must be the reason why they invented virtual ones several decades ago.> What is the reason for > the "paralleliation metadata?" It seems to me this implies/requires that > LLVM have knowledge of parallel semantics. That would be very > unfortunate.The reasons are listed in "Function Outlining" section of my proposal. You simply dimissed them with:> This is a very high-level transformation. I don't think it belongs in a low-level backend.> A higher-level IR would be more appropriate for this, either something provided by Clang or another frontend or a some other mid-level IR.> You're assuming all optimization is done by LLVM. That's not true in general.Sorry, but what you said are your opinions, not data-driven agruments. We all have opinions. The arguments I listed are supported by data presented in [Tian05], referenced in our proposal. Do you have data supporting your opinions? Yours, Andrey --- Software Engineer Intel Compiler Team Intel Corp. On Tue, Oct 2, 2012 at 5:15 AM, <greened at obbligato.org> wrote:> Hal Finkel <hfinkel at anl.gov> writes: > > Hi Hal, > >> 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) > > This link seems to be broken. I missed your earlier proposal and would > like 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 runtime routines?" What is the reason for > the "paralleliation metadata?" It seems to me this implies/requires that > LLVM have knowledge of parallel semantics. That would be very > unfortunate. > > -David
Andrey Bokhanko <andreybokhanko at gmail.com> writes:>> Again, I only skimmed the document, but I was left with the question, >> "why not just make calls to runtime routines?" > > Granted, this is the easiest and cheapest way to support OpenMP... > that throws away the whole notion of "optimizing compilation" and > "front-end / back-end decoupling".How? Nothing prevents the use of an intermediate layor to handle high-level transformation.> Wait a sec... LLVM IR is meant to be portable and supporting > "life-long program analysis and transformation". Locking it with > target machine's OpenMP runtime calls from the very beginning is not > the best way to acheive these goals. Same with physical registers -- > this must be the reason why they invented virtual ones several decades > ago.Sure, I understand the whys of the proposal and I understand that intrisics can be valuable. I don't want to lose the low-level nature of LLVM and these proposals (not just parallelization, but GPU IR, eval-style inline bitcode, etc.) are starting to feel like mission-creep. That's all. I'm not forcibly objecting to anything. Just passing on thoughts.> The reasons are listed in "Function Outlining" section of my proposal. > You simply dimissed them with:I apologize for offending you. That was certainly not my intent. -David