This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Remove TARGET_ADDR_SPACE_KEYWORDS target macro
- From: Michael Meissner <meissner at linux dot vnet dot ibm dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Mark Mitchell <mark at codesourcery dot com>, Steven Bosscher <stevenb dot gcc at gmail dot com>, GCC Mailing List <gcc at gcc dot gnu dot org>, Kai Tietz <ktietz at gcc dot gnu dot org>, Michael Meissner <meissner at linux dot vnet dot ibm dot com>
- Date: Wed, 26 May 2010 14:49:14 -0400
- Subject: Re: [patch] Remove TARGET_ADDR_SPACE_KEYWORDS target macro
- References: <20100526173206.GA5067@hungry-tiger.westford.ibm.com> <201005261809.o4QI9voH030824@d12av02.megacenter.de.ibm.com>
On Wed, May 26, 2010 at 08:09:57PM +0200, Ulrich Weigand wrote:
> Mike Meissner wrote:
> > On Wed, May 26, 2010 at 10:16:22AM -0700, Mark Mitchell wrote:
> > > Ulrich Weigand 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.
> > >
> > > Yes, the (informally agreed) policy is to have hooks, not macros. There
> > > may be situations where that is technically impossible, but I'd expect
> > > those to be very rare.
> >
> > For the target address space stuff, it is to the __ea keyword. You don't want
> > a target hook that is called on every identifier, but instead you want a target
> > hook that is called in c_parse_init (in c-parser.c) and init_reswords (in
> > cp/lex.c) to set up the keywords. The target hook would have to duplicate the
> > functionality of all of the setup that c_parse_init and init_reswords do,
> > particularly if they have different semantics.
>
> It looks like this may be simpler than I thought. The following patch
> introduces a "c_register_addr_space" routine that the back-end may call
> to register a named address space qualifier keyword. (This could be done
> either statically at start-up, or even dynamically e.g. in respose to a
> target-specific #pragma.)
>
> In the current patch, the SPU back-end uses somewhat of a hack to actually
> perform that call: it is included in the REGISTER_TARGET_PRAGMAS macro.
> Note that this macro is already being used by the SPU and several other
> back-end for similar hacks. It seems that it might be a good idea to
> replace this by something like a "register_target_extensions" callback
> in targetcm, but that can probably be done in a separate patch.
Note, many of the things done by REGISTER_TARGET_PRAGMAS deal with the
preprocessor and keywords, which are used by the C-like front ends, but not
used for Ada, Fortran, etc. Those front ends don't link in libcpp. So, you
need something in <machine>-c.c that sets the hook, rather than moving it to
<machine>.c.
--
Michael Meissner, IBM
Until June 14: 4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
After June 14: 5 Technology Place Drive, MS 2757, Westford, MA 01886, USA
meissner@linux.vnet.ibm.com