This is the mail archive of the gcc@gcc.gnu.org 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: Question about Gimple FE


On Fri, Apr 3, 2015 at 7:56 PM, Gry Gunvor <gry.gunvor@gmail.com> wrote:
> Gcc melt already advertises that it allows access to the internals:
> http://gcc-melt.org/ ; I have not tried it yet.
>
> This is of course not the same as a format that can be exported and
> then imported again, but it is attempting to get a similar result.
>
> (1) Can anyone comment on the quality/usability/performance of the
> melt approach?
>
> (2) Since melt is attempting to get a similar effect, it must be
> slicing the gcc internals in a similar way.  If melt does what it
> says, one could write a gimple exporter in it, though I don't know
> about an importer.
>
> In any case, it seems that half the problems that would be encountered
> have already been encountered by melt, so it could be informative to
> hear from melt developers/users.

Melt is not part of GCC thus it isn't appropriate to use it.

Richard.

> Gry
>
>
> On Fri, Apr 3, 2015 at 10:05 AM, Richard Biener
> <richard.guenther@gmail.com> wrote:
>> On April 3, 2015 5:41:35 PM GMT+02:00, Diego Novillo <dnovillo@google.com> wrote:
>>>On Fri, Apr 3, 2015 at 11:35 AM, Jeff Law <law@redhat.com> wrote:
>>>> On 04/03/2015 09:30 AM, Diego Novillo wrote:
>>>>>
>>>>> On Fri, Apr 3, 2015 at 11:10 AM, xue yinsong
>>><xyshh94225@hotmail.com>
>>>>> wrote:
>>>>>
>>>>>> So itâs better not to try to read the exact dump format.
>>>>>> Could we use a similar but more complete syntax instead?
>>>>>
>>>>>
>>>>> Absolutely. The initial attempt for gimple fe was to use a
>>>tuple-based
>>>>> syntax that is very easy to parse. But that was only chosen because
>>>it
>>>>> simplifies parsing.
>>>>>
>>>>> You first need to design a text representation for the IL that
>>>allows
>>>>> conveying all the elements needed to instantiate the in-memory
>>>>> representation of gimple.
>>>>
>>>> Crazy idea, what about something that's modeled after LLVM's
>>>representation?
>>>
>>>I was hesitant to offer this option, but it's certainly a good
>>>starting point.  The representation encodes CFG, SSA, attributes,
>>>declarations and annotations.  It has a relatively fixed syntax, which
>>>makes it easy to parse.
>>
>> The other way is to reuse an existing frontend and add extensions so you can annotate stuff or use obscure middle end features.  Like the C frontend.
>>
>> Richard.
>>
>>>
>>>Diego.
>>
>>


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