Re: suppress_checking

[Ken Raeburn <raeburn@raeburn.org>]

On Oct 30, 2007, at 1:24, Richard Stallman wrote:
>     Since CHECK itself just evaluates the test and does nothing  
> with it
>     if ENABLE_CHECKING is not defined, assuming you have a decent
>     optimizing compiler,
>
> We're interested in GCC, not particularly in "decent optimizing
> compilers".  Does GCC in fact optimize these cases?

Certainly GCC would be the main one I'd care about performance-wise,  
and as far as I'm concerned sets the standard for "decent optimizing  
compilers", but I've heard people do sometimes use other compilers. :-)

I haven't actually checked lately if GCC optimizes these cases, but  
given that the test is generally extracting some bits from the object  
value and comparing against a constant, or maybe doing that and then  
fetching a few bits from a computed address to compare against  
another constant, it'd be a real bug in GCC if it failed to optimize  
doing this twice in a row with the same input value and without  
intervening memory writes.  But it is possible, at least in theory,  
that some regression might cause some version of GCC to fail to  
combine the identical calculations, and that it might even escape  
notice until after a release went out.

If there are intervening memory writes or nontrivial function calls,  
and the test in question requires examining the pointed-to values  
(e.g., for misc or vector subtypes), and GCC's alias analysis (which  
is constantly being improved) can't prove they're disjoint locations,  
there would be extra reads from memory, and the associated  
comparisons, unused branches to calls to the "die" function, etc.

...  Okay, I just ran a quick test on my Mac (powerpc, Apple-flavored  
gcc 4.0.1).  The disassembly of a test function that included "if  
(STRINGP (s)) return SDATA (s);", where "s" was an argument to the  
function, showed the test was performed once, and the "die" call  
wasn't present at all.

Ken