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
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
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 >
On Wednesday 25 March 2009, Luke Dalessandro 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.I've been using this approach now for almost two years in a project and it _seems_ to work fine. However, I'd like to get some feedback from the experts on which kinds of code could be moved by the standard passes over the points in code marked by such calls. For me, loads, stores, and calls to other functions are most interesting. Do the current optimization passes do that? (For example, by checking whether a global's address would escape to external entities like the dummy function that is the marker and allowing accesses to the global to be moved if it doesn't escape.) Thanks, Torvald