diff options
author | Michal Strehovský <MichalStrehovsky@users.noreply.github.com> | 2018-11-19 09:23:22 +0100 |
---|---|---|
committer | GitHub <noreply@github.com> | 2018-11-19 09:23:22 +0100 |
commit | 497419bf8f19c649d821295da7e225e55581cce9 (patch) | |
tree | 5f2813fefef41417a102627277db2fb01b76d7d3 /NuGet.Config | |
parent | d76d97ffc9ba23e6eec30536c6f07756e08151f2 (diff) | |
download | coreclr-497419bf8f19c649d821295da7e225e55581cce9.tar.gz coreclr-497419bf8f19c649d821295da7e225e55581cce9.tar.bz2 coreclr-497419bf8f19c649d821295da7e225e55581cce9.zip |
Make type comparisons more general purpose (#20940)
This has two parts:
## Part 1
CoreRT represents native type handles differently from CoreCLR - on CoreCLR, `RuntimeTypeHandle` is a wrapper over `RuntimeType` and RyuJIT is aware of that. On CoreRT, `RuntimeTypeHandle` wraps the native type handle, not a `RuntimeType`.
The knowledge is hardcoded in importer when importing the sequence "ldtoken foo / call Type.GetTypeFromHandle" - importer just removes the call and bashes the result of ldtoken to be a reference type. CoreRT had to avoid reporting `Type.GetTypeFromHandle` as an intrinsic because of that.
I'm adding another helper that lets RyuJIT avoid hardcoding that knowledge. Instead of just bashing the return type, we swap the helper call.
## Part 2
Native type handle equality checks need to go through a helper, unless the EE side says it's okay to compare native type handles directly.
Diffstat (limited to 'NuGet.Config')
0 files changed, 0 insertions, 0 deletions