On Wed, Jan 2, 2019 at 7:48 PM Michael Matz <matz....@frakked.de> 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. > 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 > Tinycc-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tinycc-devel _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
