@diml suggested that branches containing code always ending in "raise" should be lifted into separate functions, since they are often slow paths, and their presence may inhibit inlining of the enclosing function (e.g. when there is a lot of code to build an error message before the raise).
Another way to achieve the same result would be some kind of partial inlining with the original function receiving multiple entry points (in particular a new entry point at the start of the block not being inlined).
A first experiment could operate by lifting so we could assess the performance. I'm a bit uncertain that multiple entry points are a good idea as perhaps they might conflict with restrictions of some of the more complicated ABIs out there.
This should be done after the initial version of the CPS work is completed. The suggested experimental version would also need the restriction removing that closed functions with specialised arguments cannot be lifted. That could probably be done by splitting functions' code from set-of-closures definitions, and is something we should do in any case.
@diml suggested that branches containing code always ending in "raise" should be lifted into separate functions, since they are often slow paths, and their presence may inhibit inlining of the enclosing function (e.g. when there is a lot of code to build an error message before the raise).
Another way to achieve the same result would be some kind of partial inlining with the original function receiving multiple entry points (in particular a new entry point at the start of the block not being inlined).
A first experiment could operate by lifting so we could assess the performance. I'm a bit uncertain that multiple entry points are a good idea as perhaps they might conflict with restrictions of some of the more complicated ABIs out there.
This should be done after the initial version of the CPS work is completed. The suggested experimental version would also need the restriction removing that closed functions with specialised arguments cannot be lifted. That could probably be done by splitting functions' code from set-of-closures definitions, and is something we should do in any case.