Re: [PATCH] powerpc: Make BUG_ON & WARN_ON play nice with compile-time optimisations

[Michael Ellerman <michael@ellerman.id.au>]

[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]

On Tue, 7 Feb 2006 16:22, Michael Ellerman wrote:
> Currently if you do BUG_ON(0) you'll still get a trap instruction in your
> object, although it'll never trigger. That's ok, but a bit ugly, it'd be
> nice if the compiler could completely eliminate any trace of the BUG_ON.
>
> So update the BUG_ON & WARN_ON macros to make this possible. From the
> comment in the patch:
>
>  The if statement in BUG_ON and WARN_ON gives the compiler a chance to do
>  compile-time optimisation and possibly elide the entire block. The check
>  for !__builtin_constant(x) has the oppposite effect, if we must do the
>  test at runtime then we avoid a spurious compare and branch by ensuring
>  the if condition is always true.
>
> I've confirmed it works in both cases, if the condition is false at compile
> time we get no code emitted for the BUG statement. If the condition needs
> to be evaluated at runtime we get the same code we used to, ie. only one
> test in the trap instruction.

Turns out this doesn't always do what we want, depending on what the condition 
for the BUG_ON() is. Specifically the __builtin_constant_p() sometimes fails 
to recognise that the condition will be constant, and so we end up with:

 558:   38 00 00 00     li      r0,0
 55c:   0b 00 00 00     tdnei   r0,0

Which is harmless but not really good enough. When gcc gets fixed 
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26724) we can think about this 
again.

cheers

-- 
Michael Ellerman
IBM OzLabs

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]