Re: [gimplefe] [gsoc16] Gimple Front End Project

[Richard Biener <richard dot guenther at gmail dot com>]

On March 8, 2016 4:42:41 PM GMT+01:00, "Manuel LÃpez-IbÃÃez" <lopezibanez@gmail.com> wrote:
>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?

I'd say a dump modifier -il to make it dump IL only (maybe into a different file) plus required global info such as types would be enough.

>> 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

Yes.

>>> 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.

For any kind of unit testing you need to develop some pass manager support.

>>>> 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.

True.  But as far as a GSoC scoped project goes I strongly suggest to re-use the C FE to save you from paesing declarations and the required GENERIC building.

Also note my suggestion that all GIMPLE sources should be valid C as well it would be unfortunate to lose the option to torture unit tests.

Richard.

>Cheers,
>
>	Manuel.