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.guent...@gmail.com> wrote: > On April 3, 2015 5:41:35 PM GMT+02:00, Diego Novillo <dnovi...@google.com> > wrote: >>On Fri, Apr 3, 2015 at 11:35 AM, Jeff Law <l...@redhat.com> wrote: >>> On 04/03/2015 09:30 AM, Diego Novillo wrote: >>>> >>>> On Fri, Apr 3, 2015 at 11:10 AM, xue yinsong >><xyshh94...@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. > >
