ReadyToRun: Tailcalls not supported

[KevinRansom]

Compiling F# code with crossgen I see:

Not implemented (Exception from HRESULT: 0x80004001 (E_NOTIMPL)) while compiling method basicNumberToString@860-559.Invoke
ReadyToRun: Explicit tailcalls not supported

We should ensure that .tail is supported.

Kevin

theme:tail-call

[dsyme]

So I'm wondering why this is this not supported? NGEN has always supported tailcalls (at least in recent years). And there have always been many tests to ensure CLR support for tailcalls didn't regress :/

Do we have any info on the ramifications of this, or what's needed to support it?

Thanks

[jkotas]

The fundamental problem with slow tailcalls is that we need more sane way to implement them.

• For R2R on Windows, it is needed to have a reasonable ABI that we can maintain version resiliency for. (We will fallback to JIT for them.)
• For Unix (https://github.com/dotnet/coreclr/issues/2556), it is needed to avoid writing 1000+ lines of dynamically emitted assembly code that will be a giant bug farm. (They will be turned into regular calls on Unix.)

cc @janvorli since he is going to look into this.

[jkotas]

We may be able to enable the fast tailcalls for R2R, but it requires teaching delay load fixups about them (the delay load fixups are not able to reliably find the indirection cell used by the tailcall - tried it in dotnet/coreclr#4984).

[dsyme]

@jkotas Thanks for the details. I have to agree that it's really, really critical for F# on .NET Core to get this sorted out - both "crossgen" and tailcalls on Unix.

Among other things, many parts of the F# compiler toolchain itself depend on indirect tailcalls being taken, especially when processing large inputs.

[jkotas]

We may be able to enable the fast tailcalls for R2R, but it requires teaching delay load fixups about them

We should look into fixing this for .NET 5. It is becoming more of a problem.

[VSadov]

Is tailcalling fcalls any easier than regular methods? Or it is largely the same problem?