-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
JIT: Optimize struct parameter register accesses in the backend #110819
base: main
Are you sure you want to change the base?
JIT: Optimize struct parameter register accesses in the backend #110819
Conversation
This PR adds an optimization in lowering to utilize the new parameter register to local mappings added in dotnet#110795. The optimization detects IR that is going to result in stack spills/loads and instead replaces them with scalar locals that will be able to stay in registers. Physical promotion benefits especially from this as it creates the kind of IR that the optimization ends up kicking in for. The heuristics of physical promotion are updated to account for the fact that the backend is now able to do this optimization, making physical promotion more likely to promote struct parameters.
Does this fix #89374? |
No -- currently I'm just looking at ensuring that physical promotion is able to handle the cases that old promotion can handle. This change should only result in a small number of diffs since old promotion handles the vast majority of structs passed in registers today, but it gets us closer to removing old promotion entirely. |
For GC refs in structs these have to be zeroed anyway, so we might as well just spill to the original parameter as well as the new mapping. This means we can avoid the manually inserted spill in the init block, and we retain the property that parameters are fully defined by the prolog.
If they are DNER they definitely will not stay in a register
This PR adds an optimization in lowering to utilize the new parameter
register to local mappings added in #110795. The optimization detects IR
that is going to result in stack spills/loads and instead replaces them
with scalar locals that will be able to stay in registers.
Physical promotion benefits especially from this as it creates the kind
of IR that the optimization ends up kicking in for. The heuristics of
physical promotion are updated to account for the fact that the backend
is now able to do this optimization, making physical promotion more
likely to promote struct parameters.
Based on #110795