This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bit twiddling builtins


Falk Hueffner <falk.hueffner@student.uni-tuebingen.de> writes:

> Richard Earnshaw <rearnsha@arm.com> writes:
> 
> > rth@gcc.gnu.org said:
> > > 	* config/arm/arm.c (arm_init_builtins): Rename __builtin_clz to
> > > 	__builtin_arm_clz. 
> > 
> > The changes made to the ARM part can't be right. Either:
> > 
> > 1) The new code completely replaces the ARM builtin_clz, in which case the 
> > existing ARM builtin should be removed, since it is now redundant, or
> > 
> > 2) The new code implements different functionality, in which case you've 
> > just silently broken any existing code that already makes use of the 
> > builtin (given it a different meaning).
> 
> The new __builtin_clz has the same semantic as the old one, except
> that its value at 0 isn't defined, whereas for the ARM builtin it is
> 32.  However, constant folding and libgcc2 already return 32 for this
> case; so if ARM's machine description also does that (which would be
> very easy to do by simply using the clz opcode), the behaviour doesn't
> change, and the __builtin_arm_clz can be removed. Does that sound
> acceptable? I could try making a patch, but I couldn't test it...

I think this was probably a mistake.  Instead, ports should be able to
specify the value of clz at 0.

On powerpc, one of the most important uses of clz is that you can write

__builtin_clz(x) >> 5

instead of

x == 0

which allows removal of the branch; but this doesn't work if clz
doesn't return 32 at 0.

Likewise, you can implement ffs using clz, but you have to know what
the value at 0 is.

-- 
- Geoffrey Keating <geoffk@geoffk.org>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]