On Mon, Mar 21, 2016 at 04:43:35AM +0530, Prasad Ghangal wrote:
> Hi!
>
> Sorry for the late reply.
>
> I was observing gimple dumps and my initial findings are, to parse
> gimple, we have to add support for following components to C FE
>
> *basic blocks
I'd think you can probably make these enough like C labels that you
don't need to do anything special in the C fe to parse these. Just
removing the < and > gets you pretty close is that it?
> *gimple labels and goto
Similar I think.
> *gimple phi functions
> iftmp_0_1 = PHI (ftmp_0_3, iftmp_0_4)
yesI think you need to add something here. I think you can do it as a
builtin type function that expects its arguments to be labels or names
of variables.
> *gimple switch
> switch (a_1) <default: <L0>, case 1: <L1>, case 2: <L2>>
I'd think we could make this more C like too.
> *gimple exception handling
yeah, though note exceptions are lowered pretty quickly so supporting
them with the explicit exception syntax probably isn't particularly
important.
> *openmp functions like
> main._omp_fn.0 (void * .omp_data_i)
I'd think you'd want to change the duping of this some to make it easier
to tell from struct.some.member.
> Please correct me if I am wrong. Also point out if I am missing anything
I think you might need to do something about variable names?
Trev
>
>
>
>
> On 18 March 2016 at 14:53, Richard Biener <richard.guent...@gmail.com> wrote:
> > On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni
> > <prathamesh.kulka...@linaro.org> wrote:
> >> On 15 March 2016 at 20:46, Richard Biener <richard.guent...@gmail.com>
> >> wrote:
> >>> On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz <m...@suse.de> wrote:
> >>>> Hi,
> >>>>
> >>>> On Thu, 10 Mar 2016, Richard Biener wrote:
> >>>>
> >>>>> Then I'd like to be able to re-construct SSA without jumping through
> >>>>> hoops (usually you can get close but if you require copies propagated in
> >>>>> a special way you are basically lost for example).
> >>>>>
> >>>>> Thus my proposal to make the GSoC student attack the unit-testing
> >>>>> problem by doing modifications to the pass manager and "extending" an
> >>>>> existing frontend (C for simplicity).
> >>>>
> >>>> I think it's wrong to try to shoehorn the gimple FE into the C FE. C is
> >>>> fundamentally different from gimple and you'd have to sprinkle
> >>>> gimple_dialect_p() all over the place, and maintaining that while
> >>>> developing future C improvements will turn out to be much work. Some
> >>>> differences of C and gimple:
> >>>>
> >>>> * C has recursive expressions, gimple is n-op stmts, no expressions at
> >>>> all
> >>>> * C has type promotions, gimple is explicit
> >>>> * C has all other kinds of automatic conversion (e.g. pointer decay)
> >>>> * C has scopes, gimple doesn't (well, global and local only), i.e. symbol
> >>>> lookup is much more complicated
> >>>> * C doesn't have exceptions
> >>>> * C doesn't have class types, gimple has
> >>>> * C doesn't have SSA (yes, I'm aware of your suggestions for that)
> >>>> * C doesn't have self-referential types
> >>>> * C FE generates GENERIC, not GIMPLE (so you'd need to go through the
> >>>> gimplifier and again would feed gimple directly into the passes)
> >>>>
> >>>> I really don't think changing the C FE to accept gimple is a useful way
> >>>> forward.
> >>>
> >>> So I am most worried about replicating all the complexity of types and
> >>> decl
> >>> parsing for the presumably nice and small function body parser.
> >> Um would it be a good idea if we separate "gimple" functions from
> >> regular C functions,
> >> say by annotating the function definition with "gimple" attribute ?
> >
> > Yes, that was my idea.
> >
> >> A "gimple" function should contain only gimple stmts and not C.
> >> eg:
> >> __attribute__((gimple))
> >> void foo(void)
> >> {
> >> // local decls/initializers in C
> >> // GIMPLE body
> >> }
> >> Or perhaps we could add a new keyword "gimple" telling C FE that this
> >> is a GIMPLE function.
> >
> > Though instead of an attribute I would indeed use a new keyword (as you
> > can't really ignore the attribute and it should be an error with compilers
> > not knowing it). Thus sth like
> >
> > void foo (void)
> > __GIMPLE {
> > }
> >
> > as it's also kind-of a "definition" specifier rather than a
> > declaration specifier.
> >
> >>
> >> My intention is that we could reuse C FE for parsing types and decls
> >> (which I suppose is the primary
> >> motivation behind reusing C FE) and avoid mixing C statements with
> >> GIMPLE by having a separate
> >> GIMPLE parser for parsing GIMPLE functions.
> >> (I suppose the GIMPLE function parser would need to do minimal parsing
> >> of decls/types to recognize
> >> the input is a declaration and call C parsing routines for parsing the
> >> whole decl)
> >
> > Yes, eventually the C frontend provides routines that can be used
> > to tentatively parse declarations / types used in the function.
> >
> >> When C front-end is invoked with -fgimple it should probably only
> >> accept functions marked as "gimple".
> >> Does this sound reasonable ?
> >
> > I think -fgimple would only enable recognizing the __GIMPLE keyword,
> > I wouldn't change all defs to GIMPLE with it.
> >
> > Richard.
> >
> >> Thanks,
> >> Prathamesh
> >>>
> >>> In private discussion we somewhat agreed (Micha - correct me ;)) that
> >>> iff the GIMPLE FE would replace the C FE function body parsing
> >>> completely (re-using name lookup infrastructure of course) and iff the
> >>> GIMPLE FE would emit GIMPLE directly (just NULL DECL_SAVED_TREE
> >>> and a GIMPLE seq in DECL_STRUCT_FUNCTION->gimple_body)
> >>> then "re-using" the C FE would be a way to greatly speed up success.
> >>>
> >>> The other half of the project would then be to change the pass manager
> >>> to do something sensible with the produced GIMPLE as well as making
> >>> our dumps parseable by the GIMPLE FE.
> >>>
> >>> Richard.
>
>
>
> --
> Thanks and Regards,
> Prasad Ghangal
