[LLVMdev] Support for per-loop pragma

Junjie Gu jgu222 at gmail.com
Wed Jun 2 16:37:15 PDT 2010


On Wed, Jun 2, 2010 at 3:29 PM, Devang Patel <devang.patel at gmail.com> wrote:
> 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 backend's
>> job, not the front end's.
>
> The front-ends (llvm-gcc and clang) typically lower their internal AST
> into llvm IR. The front-end's will  have to do a job of attaching
> pragma to respective AST node any way. Which node will it chose to
> annotate #pragma, irrespective of how it is annotated ?

For a loop pragma, I am thinking that it should annotate #pragma on
the head basic block of the following loop (or a branch instruction
that forms a back edge for this loop, as suggested by Chris and
others).


>
>> If the only concern is that it is hard for pragma intrinsics to stay
>> with their associated code,
>> another choice is to process pragma intrinsic at the beginning of
>> optimizer and associates
>> them to instructions by either attaching metadata to instructions and
>> some kind maps (between
>> instructions/BB to metadata, etc).
>
> Note, The loop optimizer may not be the first thing run by the
> optimizer. If you wait until loop optimizer to form loop then it may
> be too late.  Whoever is converting llvm.pragma intrinsic into
> attached metadata will likely attach metadata to immediate next
> instruction anyway.

Right, the loop optimization isn't the first thing run by the
optimizer.  I meant that we may add  a new pass that just extracts
those pragma intrinsics and make this new pass to be the first thing
run by the optimizer.

Anyway,  I will look into the alternative carefully ....

Thanks for all your comments.
Junjie

>
> -
> Devang
>




More information about the llvm-dev mailing list