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

[uso ewin]

On Thu, Jan 3, 2019 at 6:51 PM Michael Matz <address@hidden> wrote:
>
> 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.
Ok, I did not think about the possibility to do that,
but now you say that, I will definitively test this implementation.
Thanks a lot for the idea.
> 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.
>
> _______________________________________________
> Tinycc-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Well, I will at first remove the Token usage for cleanup call, because
it's buggy and ugly.
Then I will try to use label pointer for cleanup.
As it should use a lot of tcc code that are still obscure to me, I
might take time to do so.

Thanks,
Matthias.