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]

Question about Gimple FE


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.

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]