[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] Add gcc cleanup attribute support
From: |
uso ewin |
Subject: |
Re: [Tinycc-devel] Add gcc cleanup attribute support |
Date: |
Thu, 3 Jan 2019 11:21:00 +0100 |
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
- [Tinycc-devel] Add gcc cleanup attribute support, uso ewin, 2019/01/02
- Re: [Tinycc-devel] Add gcc cleanup attribute support, Christian Jullien, 2019/01/02
- Re: [Tinycc-devel] Add gcc cleanup attribute support, Michael Matz, 2019/01/02
- Re: [Tinycc-devel] Add gcc cleanup attribute support, uso ewin, 2019/01/03
- Re: [Tinycc-devel] Add gcc cleanup attribute support,
uso ewin <=
- Re: [Tinycc-devel] Add gcc cleanup attribute support, Michael Matz, 2019/01/03
- Re: [Tinycc-devel] Add gcc cleanup attribute support, uso ewin, 2019/01/04
- Re: [Tinycc-devel] Add gcc cleanup attribute support, uso ewin, 2019/01/06
- Re: [Tinycc-devel] Add gcc cleanup attribute support, uso ewin, 2019/01/08
- Re: [Tinycc-devel] Add gcc cleanup attribute support, uso ewin, 2019/01/11
- Re: [Tinycc-devel] Add gcc cleanup attribute support, uso ewin, 2019/01/15
- Re: [Tinycc-devel] Add gcc cleanup attribute support, uso ewin, 2019/01/19
- Re: [Tinycc-devel] Add gcc cleanup attribute support, Christian Jullien, 2019/01/20
- Re: [Tinycc-devel] Add gcc cleanup attribute support, uso ewin, 2019/01/21
- Re: [Tinycc-devel] Add gcc cleanup attribute support, Christian Jullien, 2019/01/21