Do not use Recursion for Expression compilation

[jogibear9988]

Maybe it's faster (or maybe not), to not Traverse the Expression Tree via recursive calls? I know, this would be a big rewrite.

Also a StackOverflow Exception could occur during expression Parsing.

see this, a StackOverflow happens with FastExpressionCompiler, with Net Framework it works

    [Test]
    public void Jit_compiler_internal_limitation2()
    {
        var blk = Block(Constant(7));
        for (int n = 0; n < 2000; n++)
        {
            blk = Block(blk);
        };

        var expr = Lambda<Func<int>>(blk);

        var c = expr.Compile();
        var compiled = expr.CompileFast();

        var obj = new TestClass1();

        Assert.AreEqual(7, compiled());
    }

[jogibear9988]

Net Frameworks ExpressionCompile fails with about 4000 loops

[dadhi]

Yep, I think at some point of time we need to replace recursion with loop and hold our own stack.

[jogibear9988]

I think Microsoft also uses, because it crashes also with a stack overflow. But later, so we have more methods in the Stack. Maybe we can reduce this

[dzmitry-lahoda]

Or disallow more than 256 items of something #89

[dadhi]

After inlining a lot of intermediate calls in TryEmit we may consider to un-roll recursion at least for some single child parents. Using the same way as in TryCollectBoundConstants

[dadhi]

To be clear it is not a recursion trampolining, we are just replacing recursion calls with loop until possible, then it still would go deeper for remaining nodes.

[dadhi]

I don't think to spend more than already done on this.