On Wed, Sep 04, 2019 at 11:59:31AM +0200, felix.winkelm...@bevuta.com wrote: > The attached patch adds two optimization rules for certain uses of > ##core#inline. It basically rewrites > > (let ((<var> (##core#inline ...))) > (<kont> ... <var> ...)) > > into > > (<kont> ... (##core##inline ...) ...) > > plus a variation on this. Removing the intermediate "let" form gives > more opportunities to merge conditionals into ##core#cond forms, > which in turn may reduce intermediate CPS lambdas.
I've pushed this patch, but I feel this really exposes a limitation
in the rewrite system because this only fixes this one specific case.
It would be better if we could somehow change the test:
(if <x>
(<var> <y>)
(<var> <z>))
to also recognise:
(if <x>
(let ((whatever (##core#inline ...)))
(let ((whatever2 (##core#inline ...)))
(<var> <y>)))
(<var> <z>))
This probably applies to other rewrites as well. Basically, any chunk
of nested inline lets with a final expression that does something else
should be detectable as being the final expression.
This is not the case for every rewrite, because reordering isn't always
allowed. It is in this case, though. This should also catch slightly
different scenarios where there's a sequence of nested inline lets.
Of course, it's nontrivial to determine when rewriting where the let
should go and how to pull apart these expressions.
I don't know how to do this, and probably you've already thought about
this, but I just wanted to put it out there, maybe someone has an idea.
Cheers,
Peter
signature.asc
Description: PGP signature
_______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
