[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: [gimplefe] [gsoc16] Gimple Front End Project
From:       Manuel López-Ibáñez <lopezibanez () gmail ! com>
Date:       2016-03-08 15:42:41
Message-ID: 56DEF2F1.1080900 () gmail ! com
[Download RAW message or body]

On 08/03/16 00:24, Trevor Saunders wrote:
>> ...which suggests that we'd want to use gimple dumps as the input
>> format to a test framework - which leads naturally to the idea of a
>> gimple frontend.
>
> Assuming you mean the format from -fdump-tree-* that's a kind of C like
> language so argues against using tooples like the existing gimple-fe
> branch.

The dumps contain a lot of (sometimes optional) unstructured information. For 
example, they show both the result of the pass and (arbitrarily unstructured) 
messages about what the pass is doing.

Wouldn't it be better to get the dumps in a more structured form (e.g., 
separating IR from debug messages) before doing this?

> That's interesting, as you sort of note the other option is to just scan
> the output dump for what you intend to check.  The remark idea is
> interesting though, the -Wsuggest-final-{method,type} warnings are
> trying to be that, and istr something else like that.
>
>> foo.c:27:10: remark: loop is not vectorizable since the iterator can be
>> modified... [-Rvectorization]
>> foo.c.35:20: ...here
>>
>> or similar, where the user passed say "-Rvectorization" as a command
>> line option to request more info on vectorization, and our test suites
>> could do this.

Isn't this what -fopt-info does? 
https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html

>> As a thought-experiment, consider that as well as cc1 etc, we could
>> have an executable for every pass.  Then you could run individual
>> passes e.g.:
>>
>>    $ run-vrp foo.gimple -o bar.gimple
>>    $ run-switchconv quux.gimple -o baz.gimple
>>
>> etc.   (I'm not convinced that it makes sense to split things up so
>> much, but I find it useful for inspiration, for getting ideas about the
>> things that we could do if we had that level of modularity, especially
>> from a testing perpective).

You can have a FE that reads gimple and outputs gimple, and allows to enable 
any individual optimization flags without an -O option, such as:

$ gimple -ftree-vrp foo.gimple -o bar.gimple

The driver could also learn about *.gimple files in order to invoke the gimple 
front-end. This way, you can use the same option names for the gimple FE and 
the rest of GCC.

Of course, ideally, the pass manager would be all modular, based on 
dependencies and re-configurable like 
http://llvm.org/docs/CommandGuide/opt.html I wonder how far away is GCC's 
middle-end from being able to do that.

>>> Piggy-backing on the C frontend makes it possible to leave all the
>>> details of types and declarations
>>> and global initializers as plain C while interpreting function bodies
>>> as "GIMPLE" when leaving the frontend.
>>
>> ...it sounds like you have a radically different implementation idea,
>> in which the gimple frontend effectively becomes part of the C
>> frontend, with some different behaviors.
>
> Well, it seems like if the existing gimple-fe is basically just a parser
> for a language we don't like there isn't much value in building off of
> it instead of writing something from scratch.
>
> Being compatable with C probably with some builtins to do SSA stuff
> seems pretty nice.  I worry some about the work to avoid folding and
> stuff, but sharing code with the c-family languages seems good if we
> can.

Sharing code is good. Extending the C (or C++?) FE to also parse gimple-C seems 
a terrible idea because how badly non-modular GCC is already. It seems better 
to make gimple-C a c-family language, so it can share functions with other 
C-family languages, but fork every function/data structure that requires 
modification.

Moreover, such a gimple-C parser should be significantly simpler than a full 
featured C parser if gimple-C is assumed to be in SSA form and all loops 
lowered to goto and the syntax is only based on modern C.

Cheers,

	Manuel.

[prev in list] [next in list] [prev in thread] [next in thread]