On Fri, 19 Jul 2019 10:55:59 +0100 Richard Sandiford <richard.sandif...@arm.com> wrote:
> Jozef Lawrynowicz <joze...@mittosystems.com> writes: > > On Fri, 19 Jul 2019 09:31:15 +0100 > > Richard Sandiford <richard.sandif...@arm.com> wrote: > > > >> Jozef Lawrynowicz <joze...@mittosystems.com> writes: > >> > > >> > From 82eadcdcbb8914b06818f7c8a10156336518e8d1 Mon Sep 17 00:00:00 2001 > >> > From: Jozef Lawrynowicz <joze...@mittosystems.com> > >> > Date: Wed, 17 Jul 2019 11:48:23 +0100 > >> > Subject: [PATCH] Implement CASE_INSENSITIVE_REGISTER_NAMES > >> > > >> > gcc/ChangeLog: > >> > > >> > 2019-07-18 Jozef Lawrynowicz <joze...@mittosystems.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, Jozef > > Thanks, > Richard
