Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Constant expression evaluation for offset calculations #9791

Closed
MichalStrehovsky opened this issue Feb 23, 2018 · 2 comments
Closed

Constant expression evaluation for offset calculations #9791

MichalStrehovsky opened this issue Feb 23, 2018 · 2 comments
Labels
area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI tenet-performance Performance related issue
Milestone
Future

Comments

@MichalStrehovsky
Copy link
Member 

.assembly extern System.Runtime { }

.assembly byrefmath { }

.class private sequential ansi sealed beforefieldinit Foo
    extends [System.Runtime]System.ValueType
{
    .field public int32 X
    .field public int32 Y
}

.method public hidebysig static int32 Main() cil managed
{
  .locals init (valuetype Foo)
  .entrypoint
  ldloca 0
  ldflda int32 Foo::Y
  ldloca 0
  sub
  ret
}

This should be possible to evaluate to a constant because the result is known at compile time. RyuJIT currently generates:

G_M30739_IG01:
       50                   push     rax
       33C0                 xor      rax, rax
       48890424             mov      qword ptr [rsp], rax

G_M30739_IG02:
       488D442404           lea      rax, bword ptr [rsp+04H]
       488D1424             lea      rdx, bword ptr [rsp]
       482BC2               sub      rax, rdx

G_M30739_IG03:
       4883C408             add      rsp, 8
       C3                   ret

category:cq
theme:basic-cq
skill-level:intermediate
cost:small
@mikedn
Copy link
Contributor

mikedn commented Feb 23, 2018

Funny, just yesterday I was looking at a piece of JIT code that, if done right, could do something like this. Thanks for the example!

MichalStrehovsky referenced this issue in dotnet/corert Feb 27, 2018
@MichalStrehovsky
Remove reflection in ValueType.Equals/GetHashCode (#5436)
32758a8 
The implementation relies on a new virtual method on `System.ValueType` that provides information about fields on a type. An override of this method is injected by the compiler when needed.

This implementation is different from what Project N does (where we inject actual overrides of both methods). The CoreRT implementation is a bit more space-saving because there is only one method that does fewer things.

This ends up being a 0.9% regression in size of a hello world app, but we do get some correctness with it and a potential to get the reflection stack completely out of the base hello world image (that one will be a huge win). We can get some of the regression back by:

* Getting RyuJIT to generate more efficient code for the offset calculation (dotnet/coreclr#16527)
* Making fewer things reflectable. We're currently generating the data for e.g. OSVERSIONINFO because it's used as a parameter in a method that is reflectable, and therefore the parameter gets boxed, and therefore it needs this data. It also drags in a fixed buffer internal type because it's a valuetype field on OSVERSIONINFO. This alone costs us 100+ bytes.
kbaladurin referenced this issue in kbaladurin/corert Mar 15, 2018
@MichalStrehovsky
Remove reflection in ValueType.Equals/GetHashCode (dotnet#5436)
b442bed 
The implementation relies on a new virtual method on `System.ValueType` that provides information about fields on a type. An override of this method is injected by the compiler when needed.

This implementation is different from what Project N does (where we inject actual overrides of both methods). The CoreRT implementation is a bit more space-saving because there is only one method that does fewer things.

This ends up being a 0.9% regression in size of a hello world app, but we do get some correctness with it and a potential to get the reflection stack completely out of the base hello world image (that one will be a huge win). We can get some of the regression back by:

* Getting RyuJIT to generate more efficient code for the offset calculation (dotnet/coreclr#16527)
* Making fewer things reflectable. We're currently generating the data for e.g. OSVERSIONINFO because it's used as a parameter in a method that is reflectable, and therefore the parameter gets boxed, and therefore it needs this data. It also drags in a fixed buffer internal type because it's a valuetype field on OSVERSIONINFO. This alone costs us 100+ bytes.
@msftgits msftgits transferred this issue from dotnet/coreclr Jan 31, 2020
@msftgits msftgits added this to the Future milestone Jan 31, 2020
@MichalStrehovsky MichalStrehovsky mentioned this issue Jul 29, 2020
Closed
@jkotas
Copy link
Member

jkotas commented Jul 29, 2020

Duplicate of #40021. (#40021 has more context.)

@jkotas jkotas closed this as completed Jul 29, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 18, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI tenet-performance Performance related issue
Projects
None yet
Milestone
Future
Development

No branches or pull requests
4 participants
@jkotas @msftgits @mikedn @MichalStrehovsky