[PATCH 1/7] bb_ioctl implementation - improved

[Denis Vlasenko]

On Monday 16 July 2007 08:59, Robin Farine wrote:
> > > >This was quite puzzling for me. Try to guess which is smallest
> > > > (on i386)? * if (f() != 0)
> > > >* if (f() < 0)
> > > >* if (f() == -1)
> > > >
> > > >Third one is smallest! gcc just does "inc eax; j[n]z label";
> > > > which is just 3 bytes:
> > >
> > > The third one is relying on implementation (un-)defined
> > > behaviour.
> 
> > It is on that fuzzy bounbary "do we want to go that far
> > for saving 1 byte of code?".
> 
> Especially when on ARM for instance, the == -1 variant is 8 bytes 
> bigger than the < 0 for a given compiler and flags. The outcome of

We have lots of if (f() == -1) comparisons too:

# grep -r 'if (.*[a-z0-9](.* -1' . | wc -l
137
# echo $((137*8))
1096

You just said that clever (== per-arch) choice of FAILED_NEGATIVE(x)
and FAILED_NONZERO(x) will save ~1k of code on ARM.

> this kind of nano-optimization is compiler specific, it may change 
> from version to version, and it depends on the target architecture 
> and compilation flags. In my opinion, it makes much more sense to 

Target arch can be dealt with #ifdefs

> go for the safe variant rather than the one that spares 1 byte on 
> architecture foo.

1 byte maybe, but 8 bytes?
--
vda