[LLVMdev] Helping the optimizer along (__assume)
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:
#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:
int foo(T* x, size_t x_len)
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