[gimplefe] [gsoc16] Gimple Front End Project

[Jeff Law]

On 03/08/2016 02:59 PM, David Malcolm wrote:
> On Tue, 2016-03-08 at 21:00 +0000, Manuel López-Ibáñez wrote:
>> On 8 March 2016 at 16:47, David Malcolm <dmalcolm@redhat.com> wrote:
>>>>> Isn't this what -fopt-info does?
>>>>> https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html
>>>>
>>>> Yes.
>>>
>>> One difference is that in this proposal, the output is emitted as a
>>> diagnostic, rather than to a file.
>>
>> -fopt-info prints to stderr by default. I haven't used the current
>> version. The original version of -fopt-info was very similar to what
>> you described above.
>>
>>> FWIW, I find those existing options to be very fiddly to use (and
>>> they're categorized as "GCC Developer Options").
>>
>> Not sure what you mean exactly by fiddly. I think they are
>> categorized
>> as "GCC Developer Options" because the main users are developers
>> working on GCC optimizations, and there has been little interest in
>> making the output consistent and user-friendly. I seem to remember
>> that the original proposal by Google devs was to make -fopt-info a
>> way
>> for users to understand how their code was or not optimized. That
>> would not match your description either, because you want to use it
>> for unit-testing, thus it will still be a "developer" option.
>>
>>>>> 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.
>>>
>>> (nods)
>>
>> Which seems orthogonal to having a gimple-fe. That is, a gcc version
>> of the llvm opt tool would be useful even if it needed to go through
>> the existing FEs. It would be very useful to unit-testing specific
>> passes or sequences of passes. It would also be pretty
>> uncontroversial. And not something that a GSoC student could even
>> attempt, given the need to spent significant time/effort in coming up
>> with an overall design for the pass manager.
>>
>>> This is possibly a silly question, but why would a custom C-like FE
>>> for
>>> a language that isn't quite C rule out torturing unit tests?  Can't
>>> we
>>> inject the gimple at the stage it was generated, and then supply
>>> various -O options to run various combinations of passes?
>>
>> Indeed.
>>
>>> (Though hacking up the C frontend might be a suitable way to
>>> prototype
>>> a dedicated gimple frontend; runs into issues of having them
>>> diverge.
>>>   I don't know how much we'd want in common vs how much has to be
>>> different)
>>>
>>> (potentially we could define a subset of e.g. C99 that would be
>>> acceptable as gimple.  I don't know if that's helpful)
>>
>> A first step would be to dump something that is parseable as a subset
>> of C. I don't think we are nowhere near that. And that would still
>> not
>> be enough, since I don't think we dump all details of gimple. The C
>> FE
>> also would need to be able to parse as gimple things like look like C
>> but are significantly different (like Fortran explicit parentheses).
>>
>> Adding stuff to the C FE might seem the fast path forward, but we
>> will
>> end up with a gimple-fe as complex as the whole C FE plus the extra
>> bits for parsing all the non-C stuff. That seems very undesirable in
>> the long run. To be clear, what I would propose if a C-like
>> representation is desired is "cp -a c cgimple", and start deleting
>> all
>> the things that are not needed by cgimple and adding all the extra
>> stuff needed.
>>
>> Since the goal seems to be to be able to dump/reload some kind of IR
>> rather than a textual representation of GIMPLE tuples, why not
>> dump/load LLVM IR? The GIMPLE=>LLVM is already implemented as a GPL
>> plugin in dragonegg.
>> http://llvm.org/devmtg/2009-10/Sands_LLVMGCCPlugin.pdf
>> It is not a suggestion, but I would like to know what you think about
>> the advantages/disadvantages.
>
> My goal for unit-testing passes is to be able to dump/reload the GIMPLE
> IR in a form that's:
>    (A) readable by both humans and programs, and
>    (B) editable by humans
>    (C) roundtrippable for some subset of the IR
>    (D) can support the input for every gimple pass (pre-CFG, CFG-before
> -SSA, CFG-with-SSA, with/without lowered switches etc)
>    (E) can support the output of every gimple pass, apart from the final
> expansion to RTL.
I'll come back to my assertion that this really should be 
reading/writing a textual LTO.

By definition, everything we need is currently streamed in/out by the 
LTO bits.  What's needed is (in essence) is to virtualize that interface 
to have textual forms.

Jeff