This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Allow case-insensitive comparisons of register names by implementing CASE_INSENSITIVE_REGISTER_NAMES PR target/70320


On Fri, 19 Jul 2019 10:55:59 +0100
Richard Sandiford <richard.sandiford@arm.com> wrote:

> Jozef Lawrynowicz <jozef.l@mittosystems.com> writes:
> > On Fri, 19 Jul 2019 09:31:15 +0100
> > Richard Sandiford <richard.sandiford@arm.com> wrote:
> >  
> >> Jozef Lawrynowicz <jozef.l@mittosystems.com> writes:  
> >> >
> >> > From 82eadcdcbb8914b06818f7c8a10156336518e8d1 Mon Sep 17 00:00:00 2001
> >> > From: Jozef Lawrynowicz <jozef.l@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  <jozef.l@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]