Re: [Tinycc-devel] Add gcc cleanup attribute support

[uso ewin]

On Thu, Jan 3, 2019 at 11:04 AM uso ewin <address@hidden> wrote:
>
> On Wed, Jan 2, 2019 at 7:48 PM Michael Matz <address@hidden> wrote:
> >
> > Hi,
> >
> > On Wed, 2 Jan 2019, uso ewin wrote:
> >
> > > I've try to add support to cleanup attribute to TCC:
> > > https://github.com/cosmo-ray/tcc/tree/cleanup
> > >
> > > Are you interested in having this feature merge in mob ?
> > > If yes it would be nice if someone could review my code
> >
> > As you found out the one-pass nature of TCC makes implementing this
> > somewhat awkward.  Though you found some inventive solution to this I
> > don't particularly like it, specifically:
> >
> > * your use of tokens instead of a symbol ID in the cleanup attribute seems
> >    wasteful: in principle a cleanup is an association of a function
> >    (representable as its name, as ID) with a decl (a Sym), so that should
> >    be the only necessary thing, not the token string representing
> >    "func(&foo)" (when the cleanup is function "func" on decl "foo").
> Your right, I've use Token, because I have a better knowledge
> of Token handling in TCC than function generation,
> and it was easier to make the first version using Token, but I should have
> change that before sending my mail here,
> I'm presently working on making this change.
>
> > * your way of dealing with the "goto forward" problem is to read and
> >    remember all tokens after the goto until you find the label (and if so
> >    do the cleanups), rereading all these tokens afterwards.
> >
> >    This feels ugly and against the one-pass nature (and is quadratic if you
> >    have very many gotos); several alternatives come to mind, though I
> >    haven't tried any of them to see if they result in less ugly code: e.g.
> >    you could remember all potentially scope-exiting gotos and check them at
> >    scope exit (redirecting them to the cleanup and then further to the real
> >    destination).
>
> Well, the problem with checking this at scope exit or at the label declaration
> is that as TCC do single pass generation, I can't go back and
> regenerate the goto.
> A way to solve this would be either to create a switch case after each label
> that might need cleanup, or a dummy function for each goto in need.
> Either way, the code needed to handle that would be a lot more complex
> that current implementation which is ~30line for handling the forward goto 
> case
> and that is call only in scope that contain cleanup variable.
>
> > I'm somewhat sympathetic to having that GCC extension, though it is one of
> > the more arcane ones that isn't trivial to support and isn't used very
> > often in the wild (did you have any software in mind that made you
> > implement the extension?).
>
> I've implement this extension for a project of mine that have an entity 
> system,
> where every entity have a refcont, so I want to add a macro that would
> automatically decref my entities at scope exit (NEW_INT_ENTITY(my_int)).
>
> The only big project I know that use cleanup is Libvirt:
> https://libvirt.org/git/?p=libvirt.git;a=search;h=HEAD;s=Sukrit+Bhatnagar;st=author
> but I don't know if TCC can compile it.
> They did this as a 2018 google summer of code project.
>

glib allow to use this too:
https://developer.gnome.org/glib/unstable/glib-Miscellaneous-Macros.html#g-autoptr

> > So the advantage of having that extensions
> > needs to be weighed fairly lightly against the disadvantage of
> > complicating TCCs sources.  IMHO your current implementation leans more on
> > the disadvantage side.  But maybe you can rework it somewhat along the
> > remarks above and it turns out more elegant?
> >
> If I use Sym but keep the dual parsing that would happen only
> when we have a goto forward and a scope containing cleanup,
> would the balance switch to the advantage side ?
>
> Thanks for the review !
> Matthias,
> >
> > Ciao,
> > Michael.
> >
> > _______________________________________________
> > Tinycc-devel mailing list
> > address@hidden
> > https://lists.nongnu.org/mailman/listinfo/tinycc-devel