Automatically apply tail call optimizations

[JaroslavTulach]

Pull Request Description

• fixes Automatically detect suitable @Tail_Call optimization #10956
• duplicates benchmarks
  • the same code is executed with and without @Tail_Call
• automatically detects too deeply recursive invocations
• and enabled tail call invocation for them

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• The documentation has been updated, if necessary.
• All code follows the
  Scala,
  Java,
• Unit tests have been written where possible.
• engine benchmarks are OK
• standard library benchmarks are OK

[JaroslavTulach]

• the commit aad4b85 is an attempt to gently revert Opt-in TCO #1219
  • basically it is inserting @Tail_Call annotation everywhere it makes sense
  • that should work, should it not?
• so we can see what was the megamorphic behavior reported by Make Tail Call Optimisation Opt-In #1217 that had to be fixed
• however the revert isn't working
  • the enso runtime won't even run
  • can't find basic symbols on objects
• I am not yet sure what's going on...

[JaroslavTulach]

Let's start from basics again:

sbt:runtime-benchmarks> benchOnly CallableBenchmarks
Benchmark                                    Mode  Cnt    Score    Error  Units
benchSumTCOfromCall                          avgt    5  749,231 ± 71,350  ms/op
benchSumTCOmethodCall                        avgt    5  410,419 ± 22,373  ms/op
benchSumTCOmethodCallWithDefaultedArguments  avgt    5  395,680 ± 20,531  ms/op
benchSumTCOmethodCallWithNamedArguments      avgt    5  400,371 ± 19,671  ms/op

is the basic result of TCO related benchmark from this branch. It is indeed slow the develop branch runs at:

Benchmark                                                       Mode  Cnt   Score   Error  Units
benchSumTCOfromCall                          avgt    5  75,386 ± 1,417  ms/op
benchSumTCOmethodCall                        avgt    5  75,965 ± 3,086  ms/op
benchSumTCOmethodCallWithDefaultedArguments  avgt    5  85,326 ± 6,681  ms/op
benchSumTCOmethodCallWithNamedArguments      avgt    5  75,170 ± 2,196  ms/op

[JaroslavTulach]

• with 0d6509c I have following results locally

Benchmark                                                Score    Error  Units
benchSumTCOfromCall                                      71,632 ±  7,940  ms/op
benchSumTCOfromCallWithTailCall                          74,268 ± 10,342  ms/op
benchSumTCOmethodCall                                    77,010 ± 15,595  ms/op
benchSumTCOmethodCallWithDefaultedArguments              72,061 ±  3,377  ms/op
benchSumTCOmethodCallWithDefaultedArgumentsWithTailCall  68,628 ±  0,750  ms/op
benchSumTCOmethodCallWithNamedArguments                  69,425 ±  2,434  ms/op
benchSumTCOmethodCallWithNamedArgumentsWithTailCall      69,752 ±  0,438  ms/op
benchSumTCOmethodCallWithTailCall                        73,485 ±  4,974  ms/op

• verifying with engine bench run

[JaroslavTulach]

The need to capture x return value and return some other value is a demonstration of the success of automatic tail call optimization! Without these additional operations the deep_xyz call gets optimized and the stack is one and not 21:

Prior to #14480 the depth of Error.throw was ignored altogether
Expecting depth of 21, but was 1

If x is an error, then the execution will return the error as x+1 will still yield an error. In case of deep_throw the panic is propagated and x+1 code is skipped.

[JaroslavTulach]

• Engine benchmarks are perfectly fine with this PR!
• the same code with or without @Tail_Call
• runs at the same speed in all TCO benchmarks!

[JaroslavTulach]

Some standard library benchmarks may get improved. For example Cross_Tab seems to indicate some improvements:

Maybe Table_Aggregate:

but clearly there are no regressions - which was the biggest reason why @Tail_Call had to be introduced. E.g. all's working well.