This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: ffs/ctz expansions using clz
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Sandra Loosemore <sandra at codesourcery dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, richard at codesourcery dot com
- Date: Wed, 08 Aug 2007 12:11:08 -0700
- Subject: Re: PATCH: ffs/ctz expansions using clz
- References: <46B13576.2040800@codesourcery.com> <87wswebggj.fsf@firetop.home>
Richard Sandiford wrote:
> Sandra Loosemore <sandra@codesourcery.com> writes:
>> This patch depends on CLZ_DEFINED_VALUE_AT_ZERO applying to the clz
>> optab as well as the clz rtl expression. I couldn't tell from reading
>> the documentation whether this is a change from its previous meaning
>> or not, but I don't think it's inconsistent with current practice in
>> all the other back ends.
>
> It is a change. I was thinking the macro ought to be tristate:
> defined always, defined for the clz rtl code only, or undefined.
> Sorry for not making that clear.
All right. Let's do the following for CLZ_DEFINED_VALUE_DEFINED_AT_ZERO:
0 - Not defined at zero.
1 - Defined at zero for the RTL "clz" instruction.
2 - Defined at zero for both the RTL "clz" instruction and the optabs
"clz" expansion.
That's backwards-compatible, as the existing definitions are all
{0,1}-valued.
Sandra, please adjust the documentation in tm.texi to reflect the
possible value "2" and your patch to test for that. With those changes,
your patch is OK.
You will of course need to define the macro to "2" in the MIPS back end
to get the benefit of your patch. Given Richard's comments, that change
is OK as well, unless he indicates otherwise.
Thanks,
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713