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: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Jozef Lawrynowicz <jozef dot l at mittosystems dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, richard dot sandiford at arm dot com
- Date: Fri, 19 Jul 2019 10:57:02 -0500
- 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, Jul 19, 2019 at 10:55:59AM +0100, Richard Sandiford wrote:
> Jozef Lawrynowicz <firstname.lastname@example.org> writes:
> > 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.
Macros also are hard to use: they do not follow the normal language rules,
they just do text replacement (and C macros are terribly weak, at that).
Some of this is made better by conventions like "always put all uses of
macro parameters in parentheses", but that itself is an extra mental load
> 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.
Maybe C++ can help here? Or maybe we can declare some hooks as inline