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? Since if I take your welcome recommendation for how to improve the macro implementation - > ...if we do keep it as a macro, we should use: > > if (reg_names[i][0] > && (CASE_INSENSITIVE_REGISTER_NAMES > ? !strcasecmp (asmspec, strip_reg_name (reg_names[i])) > : !strcmp (asmspec, strip_reg_name (reg_names[i])))) then when I make it a DEFHOOKPOD the changes in this function will look the save as above, except CASE_INSENSITIVE_REGISTER_NAMES will be targetm.case_insensitive_register_names. Thanks, Jozef > > Thanks, > Richard
