Improve inlining of <| on (GraalVM EE)

[JaroslavTulach]

Pull Request Description

Benchmark that demonstrates deep hierarchy of nested <| doesn't inline. Moving most of the "function" operators (except |>) to Function as they can only work on functions. Cloning each BuiltinRootNode before use - builtins are lightweight and cloning helps to overcome Truffle recursive inlining limit.

Important Notes

The inlining didn't work well because:

• Truffle sees recursive call to <| target and hits its default (2) inlining limit
• Function.<| is currently handled as builtin, but uses VirtualFrame - e.g. wasn't subject to Speed cascade of if statements up #6255

Checklist

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

• All code follows the
  Scala,
  Java,
• All code has been tested:
  • Unit tests continue to work
  • Benchmarks are fast on GraalVM EE

[JaroslavTulach]

The PR is ready for your review. Benchmarks are being executed, but running them locally indicates a cascade of <| is now fast enough. The generic speed up of every function is going to be tackled by

• Speed functions like <| up without forcing it to be builtin #6394

While the benchmarks seem to be fine on my local computer (0.5ms for ifBench6 and 0.8ms for ifBench6In) the server benchmark run wasn't good. Started a new benchmark run. Results are however still the same:

        <case>
            <label>org.enso.interpreter.bench.benchmarks.semantic.IfVsCaseBenchmarks.ifBench6</label>
            <scores>
                <score>1.1615075573402267</score>
            </scores>
        </case>
        <case>
            <label>org.enso.interpreter.bench.benchmarks.semantic.IfVsCaseBenchmarks.ifBench6In</label>
            <scores>
                <score>20.910878999604243</score>
            </scores>
        </case>

e.g. the ifBench6In is more than 10x slower - clearly a sign of inlining not happening.

Trying harder with 2188140 - new benchmark run is scheduled and even locally I can see some improvement (0.5ms for ifBench6 and 0.6ms for ifBench6In). However the ifBench6In is still slow on the benchmarking machine: 21.25580650263044...

Explanation

Locally I was using GraalVM EE, however the server is using GraalVM CE. One of the differences between CE and EE is handling of inlining and it shows here. CE gives up and as a result one benchmark round takes 21ms while EE keeps harder and one round then takes less then 1ms.

[JaroslavTulach]

Cloning each BuiltinRootNode before use - builtins are lightweight and cloning helps to overcome Truffle recursive inlining limit.

Builtins that don't require VirtualFrame in their method signature are explicitly inlined by #6255 (comment) - those that require VirtualFrame are "cloned" before each use. That makes Truffle believe that each call into the builtin is a call the different function.

Such a cloning is not as effective direct inlining, but certainly more effective than giving up on inlining completely due to recursive limit for inlining.