[Top][All Lists]

[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:04:45 +0100

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:
but I don't know if TCC can compile it.
They did this as a 2018 google summer of code project.

> 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 !
> Ciao,
> Michael.
> _______________________________________________
> Tinycc-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]