Optimize tailcalls even when called with different type arguments.

[TomasMikula]

This PR turns off the check that the recursive tail-call is made with the same type arguments, if the tailcall optimization is requested explicitly via @tailrec.

This allows to tail-optimize, for example, operations on type-aligned sequences.

I believe the check was there for a reason. However, the tests pass and I can't think of a case where it would be unsafe. Please let me know if I'm wrong.

[sjrd]

The check might have been there because it badly interacts with specialization.

[TomasMikula]

Indeed, thank you. I will add a check that differing type arguments must not be specialized.

[smarter]

@DarkDimius : Do you know why this restriction exist? Dotty seems to have a similar one (test/files/pos/t9647.scala from this PR does not compile in Dotty because of https://github.com/lampepfl/dotty/blob/851c3c2212b7457dedc9ad1e59ff688b17458db5/compiler/src/dotty/tools/dotc/transform/TailRec.scala#L275)

[TomasMikula]

I added a check that @specialized type parameters are unchanged in the recursive call, and both negative and positive tests involving specialized type parameters.

[hrhino]

Why do we only do this in case the method is @tailrec-annotated? The documentation claims that it's

A method annotation which verifies that the method will be compiled with tail call optimization.

and that

If it is present, the compiler will issue an error if the method cannot be optimized into a loop.

Moreover, there are plenty of places on the Internet which claim that tail-call optimization is automatic.

I can't think of a reason why I'd want to write a tail-recursive method, and have it not be optimized because I forgot the @tailrec. For extra fun, when I go to put the annotation on to check, I'll get it optimized after all!

[TomasMikula]

@hrhino I guess I just wanted to keep the change conservative.

[TomasMikula]

When I enable it wholesale, this test fails. The method invocation it is looking for is optimized away. How should I update that test so that it still checks for scala/bug#8062?

[johnynek]

Thanks for doing this! I have wanted to take a stab at this. I hope we can make it enabled by default.

[TomasMikula]

I checked with Scala 2.10.3 that scala/bug#8062 is reproducible even with the recursive call in non-tail position. I updated the test accordingly so that it doesn't interact with this PR.

(Aside: where does scalac-hash come from?)

[retronym]

The check might have been there because it badly interacts with specialization.

The restriction to only elim tail calls when type args are forwarded came in a4e5d4a, one day after the genesis of the tailcalls phase. This predated the specialization phase by four years.

@dragos do you recall if the restriction was due to astounding prescience about future interactions with specialization? Or maybe just caution?

I updated the test accordingly so that it doesn't interact with this PR.

Thanks for checking before modifying the test. Adding -g:notailcalls to the compiler options in that test case would also have worked.

Aside: where does scalac-hash come from?

https://github.com/retronym/libscala

The scripts are somewhat out of date because of changes to the format and repository of our per-commit builds. I've got new versions in https://gist.github.com/retronym/6b5cea4d94d51fbcf5d7a0587404492e

[TomasMikula]

Thanks, @retronym. I saw it used in issue descriptions and didn't know where it came from.

[adriaanm]

@dragos do you recall if the restriction was due to astounding prescience about future interactions with specialization? Or maybe just caution?

Not him, but my guess would be that at some point we also compiled to a platform that didn't erase types :-) (MSIL)

[Atry]

Looks like related to scala/bug#10493

[adriaanm]

Maybe we should push this phase back until after lambdalift? That would fix both bugs (different polymorphic instantiations of both the method and the receiver), since we're looking at erased (and specialized) types.

[TomasMikula]

Just changing tailcalls to run right after lambdalift breaks:

• 9 tests in pos,
• 16 tests in neg,
• 31 test in run,
• 5 tests in jvm,
• 15 tests in specialized.

[adriaanm]

That's pretty good :-) Thanks for trying it out!

[adriaanm]

We can start with this PR and take that investigation as a separate one for 2.13.0-M4

[adriaanm]

Good stuff @TomasMikula!

[TomasMikula]

🎉