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: Jozef Lawrynowicz <jozef dot l at mittosystems dot com>
- To: Richard Sandiford <richard dot sandiford at arm 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 11:56:51 +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> <email@example.com>
On Fri, 19 Jul 2019 10:55:59 +0100
Richard Sandiford <firstname.lastname@example.org> wrote:
> 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.
Ok great, thanks for the info,