This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On March 8, 2016 4:42:41 PM GMT+01:00, "Manuel LÃpez-IbÃÃez" <> 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
>> 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
>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
>> 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
>>> modified... [-Rvectorization]
>>> foo.c.35:20:
>>> or similar, where the user passed say "-Rvectorization" as a command
>>> line option to request more info on vectorization, and our test
>>> could do this.
>Isn't this what -fopt-info does? 


>>> 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
>>> things that we could do if we had that level of modularity,
>>> from a testing perpective).
>You can have a FE that reads gimple and outputs gimple, and allows to
>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
>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 
> I wonder how far away is
>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
>>>> as "GIMPLE" when leaving the frontend.
>>> sounds like you have a radically different implementation
>>> 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
>> for a language we don't like there isn't much value in building off
>> 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
>to make gimple-C a c-family language, so it can share functions with
>C-family languages, but fork every function/data structure that
>Moreover, such a gimple-C parser should be significantly simpler than a
>featured C parser if gimple-C is assumed to be in SSA form and all
>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.


>	Manuel.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]