-
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
Introduce insGroup/instrDesc backwards navigation #80840
Introduce insGroup/instrDesc backwards navigation #80840
Conversation
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak Issue DetailsCurrently, it is only possible to walk forwards in insGroup/instrDesc data: insGroup are in a single-linked list, and variable-sized instrDesc are packed into a memory array where function This change introduces a The instrDesc backwards walk data is taken from the "small constant" area, so some small constants get pushed to using larger instrDesc sizes. Walking backwards is done using This information is currently only used in the JitDump. Basic measurement of the benchmarks SPMI collection showed about a 2.5% increase in emitter memory usage.
|
Related: #80589 |
There's an assertion building SPC.dll on ARM:
|
TP results: |
That's not bad. I am just pasting the screenshot in case the build info gets deleted in future.
So, something to think about. |
Memory usage change from the "bytes allocated in the emitter" output of EMITTER_STATS:
|
@dotnet/jit-contrib Here's an experiment I wrote to implement full backwards navigation support in MIR (emitter insGroup/instrDesc lists). The throughput impact is minimal and the memory increase might be small enough to not matter. |
Currently, it is only possible to walk forwards in insGroup/instrDesc data: insGroup are in a single-linked list, and variable-sized instrDesc are packed into a memory array where function `emitSizeOfInsDsc()` can tell you the size of an instrDesc, and `emitAdvanceInstrDesc()` can advance an `instrDesc*` forward, but there is no facility for walking to the previous instrDesc. This change introduces a `igPrev` pointer so the insGroup list is doubly-linked. Also, each instrDesc is annotated with 4 or 5 bits of data indicating how large the previous instruction in the buffer is, so it is possible to find it by subtracting that size from a `instrDesc*`. Also, each insGroup maintains an `igLastIns` pointer to the last instruction in the group, to allow seeding the backwards walk. The instrDesc backwards walk data is taken from the "small constant" area, so some small constants get pushed to using larger instrDesc sizes. Walking backwards is done using `emitGetLastIns()` to find the last instruction in the function, and `emitPrevID()` to walk to the previous one. This information is currently only used in the JitDump. Basic measurement of the benchmarks SPMI collection showed about a 2.5% increase in emitter memory usage.
d9e68d9
to
62ae1d5
Compare
/azp run runtime-coreclr superpmi-diffs, runtime-coreclr superpmi-replay |
Azure Pipelines successfully started running 2 pipeline(s). |
@dotnet/jit-contrib PTAL. I propose to check this in under |
Overall looks good approach. I am wondering if we should enable a small optimization using this functionality to verify if it is working as expected? |
There are the asserts and verifications I added. Also, I think @TIHan has some ideas for something that could use this. |
@TIHan @dotnet/jit-contrib I would still like to merge this change (with the new feature disabled). Code review? |
Hey @BruceForstall , I'll look at thoroughly in the morning - quick glance as it looks fine to me assuming we are ok with the TP and memory costs. |
Note that all this code is disabled for now, so the decision about memory/TP cost will have to come along with an optimization client that wants to turn it on. |
Will need to use this asap for two peephole opts that I want to do. |
Currently, it is only possible to walk forwards in insGroup/instrDesc data: insGroup are in a single-linked list, and variable-sized instrDesc are packed into a memory array where function
emitSizeOfInsDsc()
can tell you the size of an instrDesc, andemitAdvanceInstrDesc()
can advance aninstrDesc*
forward, but there is no facility for walking to the previous instrDesc.This change introduces a
igPrev
pointer so the insGroup list is doubly-linked. Also, each instrDesc is annotated with 4 or 5 bits of data indicating how large the previous instruction in the buffer is, so it is possible to find it by subtracting that size from ainstrDesc*
. Also, each insGroup maintains anigLastIns
pointer to the last instruction in the group, to allow seeding the backwards walk.The instrDesc backwards walk data is taken from the "small constant" area, so some small constants get pushed to using larger instrDesc sizes.
Walking backwards is done using
emitGetLastIns()
to find the last instruction in the function, andemitPrevID()
to walk to the previous one.This information is currently only used in the JitDump.
Basic measurement of the benchmarks SPMI collection showed about a 2.5% increase in emitter memory usage.