-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make sure we tell the same lie to the JIT for default interface methods #708
Make sure we tell the same lie to the JIT for default interface methods #708
Conversation
Does this line not just deal with the stub itself requiring runtime lookup? Is that not orthogonal to the generic context?
I wasn't able to find this test, can you link it? Does this test use the generic context for anything? |
Is it this one? https://github.com/dotnet/runtime/blob/master/src/coreclr/tests/src/Loader/classloader/DefaultInterfaceMethods/constrainedcall/constrained2.il Note that's a default interface method test. Crossgen2 lacks a bunch of DIM fixes still. Why is the assert not a problem for crossgen? Is this just crossgen2 sending bad input to RyuJIT because of missing DIM handling? |
I know you are asking @cshung, but this is what I would suspect. I think the following is true but please correct me if I am wrong:
class C : IEnumerable<string>, IEnumerable<object>
{
...
}
...
static void Foo<T>(C c) => ((IEnumerable<T>)c).GetEnumerator(); This is what the code you linked to is handling I believe. However, these never need generic context I believe.
|
Why are we just hitting this assert in crossgen2, and not crossgen1, even though they use the same JIT? |
e770de2
to
8370249
Compare
8370249
to
7b6e294
Compare
src/coreclr/src/tools/crossgen2/ILCompiler.ReadyToRun/JitInterface/CorInfoImpl.ReadyToRun.cs
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks ok
Backporting an LLVM fix. Fixes dotnet#708.
This pull request is intended to fix the crossgen2 compilation crash of constrained2.ilproj.
The compilation failure was found by @janvorli by running all the CoreCLR Pri 1 test on Linux under crossgen2 using SuperIlc.
Luckily, the failure reproduces itself on Windows when building a non-optimized build. The compilation crashed with an assertion here:
runtime/src/coreclr/src/jit/importer.cpp
Line 8106 in f1890a7
My first attempt was to comment out the assertion and see what happened, the test case passed. That mislead me to think the assertion could be wrong. Indeed, when I read the code around that function, I have no idea why the JIT can assert that fact, it looks like it should be handling whatever input that the
getCallInfo()
produces.Turn out, that was wrong. The assert was meant for detecting wrong data from
getCallInfo()
. The first few comments below were reacting to my wrong attempt to remove the assertion, and they are obsolete by now.A comparative study with
crossgen
revealed that the real root cause for the assert is that the VM was lying to the JIT incrossgen
butcrossgen2
wasn't lying the same way. In particular, we have this gem:runtime/src/coreclr/src/vm/jitinterface.cpp
Lines 8793 to 8796 in f1890a7
Because of the above, the
CORINFO_CALLCONV_PARAMTYPE
was not specified whencrossgen
compile the same test case, no wonder the assert is not a problem fromcrossgen
.It would be nice if we can come up with a little comment in the JIT about the handling of default interface method, the lie is just far from obvious.
@dotnet/jit-contrib
@dotnet/crossgen-contrib