This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Add "__RTL" to cc1 (v2)
On Thu, 2016-10-13 at 15:49 +0200, Richard Biener wrote:
> On Fri, Oct 7, 2016 at 5:58 PM, David Malcolm <dmalcolm@redhat.com>
> wrote:
> > On Wed, 2016-10-05 at 16:09 +0000, Joseph Myers wrote:
> > > On Wed, 5 Oct 2016, David Malcolm wrote:
> > >
> > > > @@ -1752,6 +1759,35 @@ c_parser_declaration_or_fndef (c_parser
> > > > *parser, bool fndef_ok,
> > > > c_parser_skip_to_end_of_block_or_statement (parser);
> > > > return;
> > > > }
> > > > +
> > > > + if (c_parser_next_token_is (parser, CPP_KEYWORD))
> > > > + {
> > > > + c_token *kw_token = c_parser_peek_token (parser);
> > > > + if (kw_token->keyword == RID_RTL)
> > >
> > > if (c_parser_next_token_is_keyword (parser, RID_RTL))
> > >
> > > You're missing an update to the comment above this function to
> > > show
> > > what
> > > the new syntax is.
> >
> > Thanks. Here's an updated version of the patch which fixes that,
> > along with some other fixes:
> > * Use c_parser_next_token_is_keyword.
> > * Removed a stray "FIXME".
> > * Removed some debug code.
> > * Add more comments
> > * Fixed a typo in the ChangeLog ("__RID" -> "__RTL")
> >
> > Blurb from original version:
> >
> > This patch implements Richi's idea of having a custom __RTL marker
> > in C function definitions, to indicate that the body of the
> > function
> > is to be parsed as RTL, rather than C:
> >
> > int __RTL test_fn_1 (int i)
> > {
> > (function "times_two"
> > (insn-chain
> > (note 1 0 4 (nil) NOTE_INSN_DELETED)
> > ;; etc
> > ) ;; insn-chain
> > (crtl
> > (return_rtx
> > (reg/i:SI 0 ax)
> > ) ;; return_rtx
> > ) ;; crtl
> > ) ;; function
> > }
> >
> > This allows for decls and types to be declared in C, and to use
> > the function decl from the C frontend.
> >
> > I added support for running a single pass by giving __RTL an
> > optional
> > parameter (the name of the pass). For example:
>
> So what's the default behavior?
Currently it loads the RTL, but doesn't manage to generate assembler
for it. There are some state issues to be tracked down.
int __RTL ("rtl-dfinit") test_fn_2 (int i)
> > {
> > (function "times_two"
> > (insn-chain
> > (note 1 0 4 (nil) NOTE_INSN_DELETED)
> > ;; etc
> > ) ;; insn-chain
> > (crtl
> > (return_rtx
> > (reg/i:SI 0 ax)
> > ) ;; return_rtx
> > ) ;; crtl
> > ) ;; function
> > }
>
> Does it really run a single pass only?
Yes.
> Thus you can't do a { dg-do run } test
> with __RTL?
Currently not, but I think I can fix that.
> The GIMPLE FE has a __GIMPLE (starts-with: "pass") thing
> starting from a specific pass but going all the way to assembly
> output.
It strikes me that we might need that; we probably need some way to
identify what state the RTL is in.
> It looks like your run-one-rtl-pass thingy is directly invoked from
> the "frontend"
> rather than passing down everything to the middle-end?
Yes. There are some nasty state issues here: the whole of the RTL
-handling in the backend seems to expect a single function, and various
other singleton state (e.g. "crtl" aka "x_rtl"). The RTL "frontend" is
populating that state directly, so I think I have to do one function at
a time, running any/all RTL passes as soon as each one is parsed.
[...]