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 >
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
Anthony Danalis wrote:> 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 wrote a patch added embedded metadata here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090316/075433.html which I'm sure will land "soon" (this weekend?). Unfortunately it doesn't permit the metadata to reference registers in your function (so, if you have "%x = load ..." then you can't have metadata on %x. There's always a phase two I suppose. The design is here: http://nondot.org/sabre/LLVMNotes/EmbeddedMetadata.txt Nick> 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 > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >