[LLVMdev] Helping the optimizer along (__assume)

Kenneth Boyd zaimoni at zaimoni.com
Wed Oct 22 17:47:35 PDT 2008

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 

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))

I'd like to have the following always "bubble up" syntax errors:

template<class T>
int foo(T* x, size_t 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


More information about the llvm-dev mailing list