[LLVMdev] [RFC] OpenMP Representation in LLVM IR

[Andrey Bokhanko]

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