Our relooper implementation is tail-recursive, meaning that as we process nodes in the CFG we recursively call into relooper to process the subsequent nodes. In working on #1827 I found that the threads used when running tests have a small enough stack size that we overflow the stack when trying to transpile the blake_256 test case. In that PR I work around it by spawning a thread with a larger stack, but that's not a robust solution. The proper fix here is to tweak relooper to use a loop when processing sequential nodes instead of tail-recursing after each Simple block. Should be straightforward to implement but I want to split it off of #1827 to avoid bloating that PR.
Our relooper implementation is tail-recursive, meaning that as we process nodes in the CFG we recursively call into
relooperto process the subsequent nodes. In working on #1827 I found that the threads used when running tests have a small enough stack size that we overflow the stack when trying to transpile the blake_256 test case. In that PR I work around it by spawning a thread with a larger stack, but that's not a robust solution. The proper fix here is to tweakrelooperto use a loop when processing sequential nodes instead of tail-recursing after eachSimpleblock. Should be straightforward to implement but I want to split it off of #1827 to avoid bloating that PR.