This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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>