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. Thanks, Richard
