[PATCH] [rtlfe] Barebones implementation of "__RTL"; next steps?

[Richard Biener]

On Wed, May 11, 2016 at 3:31 AM, Trevor Saunders <tbsaunde@tbsaunde.org> wrote:
> On Tue, May 10, 2016 at 05:01:00PM -0400, David Malcolm wrote:
>> [CCing Prasad since this may be useful for his gimple FE work, by
>> replacing "rtl" with "gimple" in the patch]
>>
>> On Mon, 2016-05-09 at 11:44 +0200, Richard Biener wrote:
>> > On Wed, May 4, 2016 at 10:49 PM, David Malcolm <dmalcolm@redhat.com>
>> > wrote:
>>
>> > > This patch kit introduces an RTL frontend, for the purpose
>> > > of unit testing: primarly for unit testing of RTL passes, and
>> > > possibly for unit testing of .md files.
>> > >
>> > > It's very much a work-in-progress; I'm posting it now to get
>> > > feedback.
>>
>> [...snip...]
>>
>> > > * The RTL frontend doesn't have any knowledge of the name of the
>> > > function,
>> > >   of parameters, types, locals, globals, etc.  It creates a single
>> > > function.
>> > >   The function is currently hardcoded to have this signature:
>> > >
>> > >      int test_1 (int, int, int);
>> > >
>> > >   since there's no syntax for specify otherwise, and we need to
>> > > provide
>> > >   a FUNCTION_DECL tree when building a function object (by calling
>> > >   allocate_struct_function).
>> > >
>> > > * Similarly, there are no types beyond the built-in ones; all
>> > > expressions
>> > >   are treated as being of type int.  I suspect that this approach
>> > >   will be too simplistic when it comes to e.g. aliasing.
>> >
>> > To address this and the previous issue I suggest to implement the RTL
>> > FE
>> > similar to how I proposed the GIMPLE FE - piggy-back on the C FE and
>> > thus
>> > allow
>> >
>> > int __RTL foo (int a, int b) // gets you function decl and param
>> > decls
>> > {
>> >  (insn ...)
>> > ...
>> >
>> > }
>> >
>> > int main()
>> > {
>> >   if (foo (1) != 0)
>> >     abort ();
>> > }
>> >
>> > That would also allow dg-do run testcases and not rely solely on
>> > scanning
>> > RTL dumps.
>>
>> The following is an attempt at implementing this, by adding a new
>> "__RTL" keyword, and detecting it in the C frontend, switching
>> to a custom parser for the function body.
>>
>> Does this look like the kind of thing you had in mind for the
>> RTL and gimple "frontends"?

Yes!

>> Wiring this up to the existing RTL parser might be awkward: the
>> existing RTL parser in read-md.c etc works at the level of
>> characters (read_char and unread_char from a FILE *), whereas the
>> C frontend is in terms of tokens.
>>
>> I have a patch that ports the RTL parser to using libcpp for
>> location-tracking, and another that updates it to use libcpp
>> for diagnostics.  This adds more dependency on a build-time
>> libcpp to the gen* tools.  Both patches are currently messy.
>> Potentially I could build on them and attempt to update the RTL
>> parser further, to use libcpp's tokenizer.
>>
>> Does that general approach sound sane?  In particular:
>> - is it sane to eliminate errors.c in favor of building
>> diagnostics*.c for the build machine as well as the host machine?
>> - is it sane to rewrite the read-md.c/read-rtl.c code to
>> a token-based approach, using libcpp?
>>
>> Alternatively, the shorter term approach would be to kludge
>> in reading from a FILE * in read-md.c based on where the
>> C parser has got to, with a hybrid of the two approaches
>> (character-based vs token-based).
>
> Another option is to make read-md.c use tokens, but instead of building
> libcpp for the build machine write a new token parser that is text
> compatible with the libcpp one, but just enough to do what read-md.c
> needs.  However that seems silly, and suggests just using libcpp is the
> sane thing to do :)
>
>> Thoughts?
>
> I'm not aware of any pitfalls in using libcpp in build tools, though it
> does seem slightly unfortunate to need to build so much build tool
> stuff.
>
> Thinking about this I wonder if libcpp would be useful in gengtype to
> get around some of the wierdness with headers (and maybe even
> languages?) but that doesn't need to be thought about now.

genmatch also uses libcpp, it's really convenient for the diagnostics as well.

That said, another kludge would be to simply use cpp_token_as_text
(see genmatch.c:c_expr::gen_transform), write the whole function
to a temporary file and parse that back in with read_md ;)

In my mind sth to continue prototyping is more important than to clean
this piece up righ now.

Richard.

> Trev
>