This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Target macros vs. target hooks - policy/goal is hooks, isn't it?
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: stevenb dot gcc at gmail dot com (Steven Bosscher)
- Cc: gcc at gcc dot gnu dot org (GCC Mailing List), ktietz at gcc dot gnu dot org (Kai Tietz), bje at au1 dot ibm dot com (Ben Elliston), meissner at linux dot vnet dot ibm dot com (Michael Meissner), Ulrich dot Weigand at de dot ibm dot com (Weigand Ulrich)
- Date: Wed, 26 May 2010 19:03:06 +0200 (CEST)
- Subject: Re: Target macros vs. target hooks - policy/goal is hooks, isn't it?
Steven Bosscher wrote:
> So the question is: The goal is to have hooks, not macros, right? If
> so, can reviewers please take care to reject patches that introduce
> new macros?
I don't know to which extent this is a formal goal these days, but I
personally agree that it would be nice to eliminate macros.
However, there are (or at least, used to be) some areas where using
hooks is a bit difficult, in particular where interactions between
the back-end and one particular front-end (as opposed to common code)
are concerned. This is the reason why we implemented
TARGET_ADDR_SPACE_KEYWORDS as macro (note that all the other
address-space related back-end callbacks were already implemented
as hooks to begin with).
> Kai already said on IRC last night that he can hookize
> TARGET_ENUM_VA_LIST. Could the folks who introduced
> TARGET_ADDR_SPACE_KEYWORDS please do the same?
I'll have a look. What is the preferred solution these days for
hooks between the C front-end and a back-end? targetcm?
(Why is there both targetcm and targetm.c ?)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com