Hi, I'm interested in whether or not there is a way of providing source-level annotations to help LLVM with optimizations, similar to VisualC++'s __assume facility (http://msdn.microsoft.com/en-us/library/1b3fsfxw.aspx). As part of our PHP compiler (phpcompiler.org), it would be great to be able to annotate our generated C code with, for example, (var !NULL), or (var->type == STRING), and have that information passed around (esp interprocedurally at link-time) by the LLVM optimizers. It would also greatly simplify our code generation. I can provide a detailed example if what I'm asking is unclear... Thanks in advance, Paul phpcompiler.org -- Paul Biggar paul.biggar at gmail.com
On Wed, Oct 22, 2008 at 3:28 PM, Paul Biggar <paul.biggar at gmail.com> wrote:> Hi, > > I'm interested in whether or not there is a way of providing > source-level annotations to help LLVM with optimizations, similar to > VisualC++'s __assume facility > (http://msdn.microsoft.com/en-us/library/1b3fsfxw.aspx).No, nothing of the sort exists. There have been some rough discussions of what would be involved, but there isn't really a plan for how to implement it. It would probably end up being similar to TBAA. -Eli
On Wed, Oct 22, 2008 at 4:22 PM, Eli Friedman <eli.friedman at gmail.com> wrote:> It would probably end up being similar to TBAA.Sorry, I meant that the way we store such information will probably be similar to whatever we end up doing for TBAA. -Eli
On Oct 22, 2008, at 3:28 PM, Paul Biggar wrote:> As part of our PHP compiler (phpcompiler.org), it would be great to be > able to annotate our generated C code with, for example, (var !> NULL), or (var->type == STRING), and have that information passed > around (esp interprocedurally at link-time) by the LLVM optimizers.For some odd reason I was thinking this was going to be done with an assert (or a special no code generating assert). Just gen up assert (i != 0); and put it in anytime it is true. The optimizers in the fulness of time would the recognize and propagate this information.
On Oct 22, 2008, at 3:28 PM, Paul Biggar wrote:> Hi, > > I'm interested in whether or not there is a way of providing > source-level annotations to help LLVM with optimizations, similar to > VisualC++'s __assume facility > (http://msdn.microsoft.com/en-us/library/1b3fsfxw.aspx).There is a way to provide source level annotations. int * foo (int *x __attribute((annotate("I_say_not_null")))) { return x; } llvm-gcc will produce following IR @.str = internal constant [9 x i8] c"/tmp/a.c\00", section "llvm.metadata" ; <[9 x i8]*> [#uses=1] @"\01LC" = internal constant [15 x i8] c"I_say_not_null\00" ; <[15 x i8]*> [#uses=1] define i32* @foo(i32* %x) nounwind { entry: %x_addr = alloca i32* ; <i32**> [#uses=1] %x_addr1 = bitcast i32** %x_addr to i8* ; <i8*> [#uses=1] call void @llvm.var.annotation(i8* %x_addr1, i8* getelementptr ([15 x i8]* @"\01LC", i32 0, i32 0), i8* getelementptr ([9 x i8]* @.str, i32 0, i32 0), i32 1) ret i32* %x } However, this mechanism (or other alternative approaches suggested by others) has not been extended to communicate annotated information meaning to LLVM optimization passes. - Devang> > > As part of our PHP compiler (phpcompiler.org), it would be great to be > able to annotate our generated C code with, for example, (var !> NULL), or (var->type == STRING), and have that information passed > around (esp interprocedurally at link-time) by the LLVM optimizers. It > would also greatly simplify our code generation. > > I can provide a detailed example if what I'm asking is unclear... > > > Thanks in advance, > Paul > phpcompiler.org > > -- > Paul Biggar > paul.biggar at gmail.com > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev- Devang
On 2008-10-22, at 19:24, Mike Stump wrote:> On Oct 22, 2008, at 3:28 PM, Paul Biggar wrote: > >> As part of our PHP compiler (phpcompiler.org), it would be great to >> be able to annotate our generated C code with, for example, (var != >> NULL), or (var->type == STRING), and have that information passed >> around (esp interprocedurally at link-time) by the LLVM optimizers. > > For some odd reason I was thinking this was going to be done with an > assert (or a special no code generating assert). Just gen up assert > (i != 0); and put it in anytime it is true. The optimizers in the > fulness of time would the recognize and propagate this information.Can't you implement __builtin_assume(cond) to codegen to something like: %cond = i1 ... br i1 %cond, label %always, label %never never: unreachable always: Then in assert.h: #ifdef NDEBUG # define assert(cond) __builtin_assume((cond)) #else # define assert(cond) ... #endif — Gordon
Mike Stump wrote:> On Oct 22, 2008, at 3:28 PM, Paul Biggar wrote: > >> As part of our PHP compiler (phpcompiler.org), it would be great to be >> able to annotate our generated C code with, for example, (var !>> NULL), or (var->type == STRING), and have that information passed >> around (esp interprocedurally at link-time) by the LLVM optimizers. >> > For some odd reason I was thinking this was going to be done with an > assert (or a special no code generating assert). Just gen up assert > (i != 0); and put it in anytime it is true. The optimizers in the > fulness of time would the recognize and propagate this information. >The Microsoft implementation is scary. I'd be much happier with __assume if it caused a syntax error in the misprint example given. One generalization I would like to see (perhaps after spending enough time to understand how to safely inject attributes or _Pragma via macros) is how to make an assert generate syntax errors when it is provably violated even in release mode. This gets even better if you control the intermediate format and can store the flow-of-control syntax error conditions with the bytecode representation of the function. (Am I misreading C99/C0X/C++98/C++0x: does the exact specification of the expansion of assert in release mode prohibit slipping in a _Pragma or other implementation-extension constructs to inject flow of control constraints?) That is, instead of hoping for an extern "C" function so that a debug wrapper could be written to check function preconditions as: #ifndef NDEBUG #ifdef assert #define foo(x,x_len) (assert(NULL!=x),assert(0<x_len),foo(x,x_len)) #endif #endif I'd like to have the following always "bubble up" syntax errors: template<class T> int foo(T* x, size_t x_len) { assert(NULL!=x); assert(0<x_len); // .... } and then.... const char* test = NULL; foo(test,0); // two syntax errors in both release and debug modes is so much better than a runtime error only in debug mode Kenneth
Doesn't llvm-gcc support GCC's builtin_expect? Or does it transform it into nothing? On Wed, Oct 22, 2008 at 6:28 PM, Paul Biggar <paul.biggar at gmail.com> wrote:> Hi, > > I'm interested in whether or not there is a way of providing > source-level annotations to help LLVM with optimizations, similar to > VisualC++'s __assume facility > (http://msdn.microsoft.com/en-us/library/1b3fsfxw.aspx). > > As part of our PHP compiler (phpcompiler.org), it would be great to be > able to annotate our generated C code with, for example, (var !> NULL), or (var->type == STRING), and have that information passed > around (esp interprocedurally at link-time) by the LLVM optimizers. It > would also greatly simplify our code generation. > > I can provide a detailed example if what I'm asking is unclear... > > > Thanks in advance, > Paul > phpcompiler.org > > -- > Paul Biggar > paul.biggar at gmail.com > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Hi Danny, On Thu, Oct 23, 2008 at 8:16 PM, Daniel Berlin <dberlin at dberlin.org> wrote:> Doesn't llvm-gcc support GCC's builtin_expect? > Or does it transform it into nothing?This isnt the same as GCC's builtin-expect, to my knowledge. Builtin_expect will leave branch prediction hints, but won't remove the branch. This would remove the branch. There was a discussion of adding this to GCC a long time ago (http://gcc.gnu.org/ml/gcc/2003-11/msg00324.html), but it looks like nothing came of it, though you probably know better than me. Paul -- Paul Biggar paul.biggar at gmail.com
On Oct 23, 2008, at 12:16 PM, Daniel Berlin wrote:> Doesn't llvm-gcc support GCC's builtin_expect?Yes, it supports it.> Or does it transform it into nothing?Yep, that's how. :) As Paul said, this is related but different than builtin_expect though. -Chris