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

[Michael Matz]

Hi,

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
> >    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.

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
   }
   later1:
   ...
   later2:

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?


Ciao,
Michael.