On Mon, Mar 21, 2016 at 4:35 AM, Trevor Saunders <tbsau...@tbsaunde.org> wrote:
> 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.
Yes.
>> *gimple switch
>> switch (a_1) <default: <L0>, case 1: <L1>, case 2: <L2>>
>
> I'd think we could make this more C like too.
switch (a_1) { default: goto L0; case 1: goto L1; ... }
which is what it boils down to. And yes, we need to adjust label dumping to
dump C-parseable labels.
>> *gimple exception handling
>
> yeah, though note exceptions are lowered pretty quickly so supporting
> them with the explicit exception syntax probably isn't particularly
> important.
True - though if we lowered things already we need to dump/parse the
EH side-info present on the stmts plus the landing pads. I'd simply defer
the issue of EH until at least some of the basic stuff works (read: not in
the GSoC project).
>> *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.
it's just the way we name clones, yes. Similar for the parameter name btw.
>> 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?
Possibly about how we dump SSA names and how we dump local variable
declarations.
Richard.
> 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
