https://sourceware.org/bugzilla/show_bug.cgi?id=34104
Maciej W. Rozycki <macro at orcam dot me.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |macro at orcam dot me.uk
--- Comment #1 from Maciej W. Rozycki <macro at orcam dot me.uk> ---
Thank you for your proposal.
This might best be discussed at the binutils mailing list,
<[email protected]>.
A couple of points:
1. I've glanced over the patch proposed and nothing clearly wrong stands
out. It would help if you stated exactly what kind of issue you've
come across that has blocked you.
2. I'm inconvinced adding these macros to GAS is a good idea in the first
place, what is the supposed use case?
Traditionally MIPS assembly macros have been provided to make the
dialect regular when it comes to operations and operands, such as to
provide the complete set of relational operations given the limited
subset of actual machine instructions or to simplify constant and
address references. It seems not to apply here, so what is the
intended purpose of these new macros?
Also some of these sequences are exceedingly long, which is another
argument against.
NB you can use the `.macro' pseudo-op to define your own operations
for use in your code.
3. Conversely, I fully support implementing GCC CLZ/CTZ RTL operations
using the proposed code sequences, presumably using suitable expanders
and scratch registers rather than just $at so as to let GCC schedule
resulting code according to its knowledge of the CPU pipeline.
Please refer to GCC documentation as to the supported arrangements for
the operand of 0; if the result is defined as -1, then it's as good as
any that is outside of the range of the bit numbers. If you need a
separate sequence for FFS, then I suggest to check if the compiler is
able to come up with an equivalent one by just using CTZ.
I don't think GCC has any support for CLO/CTO operations.
I take it this scores better benchmark results than generic code GCC
comes up with, right? And I think the longer sequences will best be
limited to libcalls when optimising for size.
--
You are receiving this mail because:
You are on the CC list for the bug.
