llvm dev - Oct 2008 - [LLVMdev] Helping the optimizer along (__assume)

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

On Oct 22, 2008, at 5:47 PM, Kenneth Boyd wrote:
> 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.
I like this idea.  Sounds good.  One can imagine enrolling static  
analysis and automated theorem provers to help out on the harder  
problems.  :-)
> (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?)
Technically, yes, but we can reword future standards to have the  
latitude to give compilation errors for conditions that can be proved  
to be false, then the implementation is conforming.  We could always  
have a flag to control the behavior if people want/need it, though, I  
can't hardly see why they'd want it to compile if they assert  
something that is false.

> Technically, yes, but we can reword future standards to have the  
> latitude to give compilation errors for conditions that can be proved  
> to be false, then the implementation is conforming.  We could always  
> have a flag to control the behavior if people want/need it, though, I  
> can't hardly see why they'd want it to compile if they assert  
> something that is false.
you never seen assert(0 && "Not yet implemented"); ?
You may want to compile a program like this :)

regards,

Cédric