-
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
Deduplicate some HWI codegen code #65302
Conversation
Tagging subscribers to this area: @JulieLeeMSFT Issue DetailsI've been taking a look at some x86 codegen-related issues recently, and solving one of them requires supporting containment for sources of However, the code for determining how exactly should this be handled is not "trivial", so to support that change, I am first making this one, which introduces a new helper class, @tannergooding curious to know of your opinion on this.
|
c6fef0f
to
ee3a298
Compare
ee3a298
to
5f9c731
Compare
@dotnet/jit-contrib |
Talked with Single about this in Discord. I think simplifying some of the checks/logic here is general goodness. In particular I like how most of the checks around which form to pick are centralized. The individual paths then just need to worry about passing the args along to the right emit method. It might be good to see if it can be extended to the areas outside of HWI as well, such as to |
/azp run runtime-coreclr jitstress |
Azure Pipelines successfully started running 1 pipeline(s). |
I've been taking a look at some x86 codegen-related issues recently, and solving one of them requires supporting containment for sources of
PUTARG_STK/FIELD_LIST
nodes.However, the code for determining how exactly should this be handled is not "trivial", so to support that change, I am first making this one, which introduces a new helper class,
OperandDesc
, and a method to create one, to help codegen determine what emitter methods should be called, in case there are multiple possibilities.No diffs as expected.
@tannergooding curious to know of your opinion on this.