[LLVMdev] pragmas

Anthony Danalis adanalis at eecs.utk.edu
Wed Mar 25 11:41:20 PDT 2009


Thanks for the quick responses.  "disappearing function calls" is by  
far the preferred way for me, as I want my pass to work with standard  
LLVM and not a hacked version that supports extra pragmas, or  
intrinsics.  I am just new to LLVM and wanted to make sure that there  
isn't already a mechanism for passing meta-data between the user and  
the optimizer.

I am planning to contribute to the wiki soon, especially little howtos  
for things that take me a day to figure out how to do and turn out to  
be < 50 lines of code that I could have copy pasted from ... a wiki!

Anthony.

On Mar 25, 2009, at 2:31 PM, someguy wrote:

> Pre-empting Chris's inevitable response: don't add intrinsics!
>
> I really like the 'disappearing function calls' idea. Chris suggested
> practically the same thing for a previous question about adding BigInt
> support.
>
> Anthony, whichever route you take in the end, please consider
> documenting your 'code adventure' on the wiki so others can learn from
> your experience.
>
> Justing
> Registered Wiki Pimp.
>
> On Wed, Mar 25, 2009 at 8:02 PM, Luke Dalessandro
> <luked at cs.rochester.edu> wrote:
>> You could encode this information as simple library function calls  
>> and
>> then find them again in the generated LLVM IR. The client then just
>> needs a header declaring the functions and information on what they
>> mean. Since there are never any definitions of them they won't end up
>> going anywhere.
>>
>> A more ambitious plan would be to modify llvm-gcc with new __builtins
>> and create intrinsics in LLVM to map them to. There's really no
>> advantage to this other than not needing the header file while
>> compiling. There's a big disadvantage in that you end up mucking with
>> both the front end and the llvm intrinsics.
>>
>> Finally, you can modify llvm-gcc pragma handling to insert things  
>> that
>> you want, but this is more work. You have to deal with the c-parser  
>> and
>> c++ parser, and understand more of the front end internals. I would
>> avoid this unless you feel like you want pragmas that have some  
>> sort of
>> lexical semantics, and don't want to force people to use BEGIN and  
>> END
>> macros.
>>
>> Hope this is helpful,
>> Luke
>>
>> Anthony Danalis wrote:
>>> Hello
>>>
>>> Is there a "generic" pragma that is supported by LLVM and is visible
>>> by optimization passes?  or any other way for a programmer to pass
>>> meta-data information to the compiler?
>>> I am writing an analysis pass that could benefit from user provided
>>> information.  At this stage, I could like to keep the kind of
>>> information that the user can provide as general as possible.
>>> Examples would be "x, y are (not) aliased", "loop trip count =
>>> x" (where x is either a static constant, or an expression", "branch
>>> cond. is true most of the time" (or x% of the time), and other
>>> information that might be statically undecidable, but the developer
>>> knows the answer to.
>>>
>>> thanks,
>>> Anthony
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




More information about the llvm-dev mailing list