This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Allow case-insensitive comparisons of register names by implementing CASE_INSENSITIVE_REGISTER_NAMES PR target/70320
- From: Richard Sandiford <richard dot sandiford at arm dot com>
- To: Jozef Lawrynowicz <jozef dot l at mittosystems dot com>
- Cc: "gcc-patches\@gcc.gnu.org" <gcc-patches at gcc dot gnu dot org>, segher at kernel dot crashing dot org
- Date: Fri, 19 Jul 2019 10:55:59 +0100
- Subject: Re: [PATCH] Allow case-insensitive comparisons of register names by implementing CASE_INSENSITIVE_REGISTER_NAMES PR target/70320
- References: <20190718204538.63c2260f@jozef-kubuntu> <firstname.lastname@example.org> <20190719103952.02de67cf@jozef-kubuntu>
Jozef Lawrynowicz <email@example.com> writes:
> On Fri, 19 Jul 2019 09:31:15 +0100
> Richard Sandiford <firstname.lastname@example.org> wrote:
>> Jozef Lawrynowicz <email@example.com> writes:
>> > From 82eadcdcbb8914b06818f7c8a10156336518e8d1 Mon Sep 17 00:00:00 2001
>> > From: Jozef Lawrynowicz <firstname.lastname@example.org>
>> > Date: Wed, 17 Jul 2019 11:48:23 +0100
>> > Subject: [PATCH] Implement CASE_INSENSITIVE_REGISTER_NAMES
>> > gcc/ChangeLog:
>> > 2019-07-18 Jozef Lawrynowicz <email@example.com>
>> > PR target/70320
>> > * doc/tm.texi.in: Document new macro CASE_INSENSITIVE_REGISTER_NAMES.
>> > * doc/tm.texi: Likewise.
>> > * defaults.h: Define CASE_INSENSITIVE_REGISTER_NAMES to 0.
>> > * config/msp430/msp430.h: Define CASE_INSENSITIVE_REGISTER_NAMES to 1.
>> > * varasm.c (decode_reg_name_and_count): Use strcasecmp instead of
>> > strcmp for comparisons of asmspec with a register name if
>> > CASE_INSENSITIVE_REGISTER_NAMES is defined to 1.
>> I really don't think we should be adding new target macros for things
>> like this. The code is hardly on the critical path, so I don't think
>> compile time is a concern. That said...
>> So TBH I still prefer the DEFHOOKPOD suggestion. I won't object if
>> someone else wants to approve the macro version though.
> Ok, as you say, this code isn't on the critical path so I'd be happy to change
> this to a DEFHOOKPOD.
> In general, what should be considered when deciding between a hook and macro?
> Does the choice lean towards macros mainly when compile time is a concern? And
> hooks otherwise?
> Is the downside of this macro implementation compared to a DEFHOOKPOD mainly
> just the maintainability/readability of the added code?
Macros are essentially the "old way" and target hooks the "new way".
The decision was made a long time ago to move away from macros where
possible. TBH I no longer remember the reasons clearly, but I think
it was partly to avoid including so much target stuff in non-target
files, and partly in the hope that we might one day support multiple
targets in a single build. Years later, we're not much closer to the
latter and I'm not sure it's a realistic goal.
So over time various macros have been moved to hooks and new target
tests should generally use hooks if at all possible.
That said, there are some macros that are too compile-time sensitive
to be hooks or variables. BITS_PER_UNIT is the most obvious example.
Also, the current approach of using header files to control OS and
object format features makes it difficult to convert the related
macros to hooks in a natural way.