[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Michael Matz
Subject: Re: [Tinycc-devel] Add gcc cleanup attribute support
Date: Thu, 3 Jan 2019 18:27:23 +0100 (CET)
User-agent: Alpine 2.21 (LSU 202 2017-01-01)


On Thu, 3 Jan 2019, uso ewin wrote:

* 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

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.

Not the goto, but you can adjust where the goto goes to. You wouldn't link these gotos in the label->jnext members, but in some on-the-side structure (also remembering the ultimate label they would have to go to, you could probably use the existing dynarray_* code). When you reach a label definition you remove all pending gotos for that label (they don't skip over the scope exit). When you reach a scope exit all pending gotos must first go to the cleanup snippet and then to the ultimate label.

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.

That latter is what you're essentially having right now: you check if the current goto in question leaves the scope, and if so emit all the cleanup code first and then the goto. I.e. for multiple gotos you repeat the cleanup code. That seems a sensible approach (the switch approach might lead to smaller code, but this shouldn't matter much here and is more complicated).

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.

Remembering gotos would also only be done when there are pending cleanups.
It might be that you're right that it would take even more code. But I'm not so sure. The remembering and reiteration over tokens really gripes at me. E.g. think about this code:

   { int a CLEANUP(foo);
     ...  goto later1; ...
     ...  goto later2; ...
     large chunk of code

For both gotos you iterate over the large chunk of code shifting tokens back and forth between the token strings and the parser. As I said, it's a cute trick to get what you need, but there has to be a better way.

We could also declare that forward jumps within scopes needing cleanups is simply not supported in TCC (with an appropriate error message). I would prefer even that crippling of the support compared to the token sifting.

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 ?

A bit, but the dual parsing makes me really unhappy :-) Do you have cycles for trying an alternative approach to at least compare both?


reply via email to

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