-
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
GitHub_17777 test failing on linux-arm64 #64162
Comments
Tagging subscribers to this area: @JulieLeeMSFT Issue DetailsFrom outerloop (Pri1) test log: https://helix.dot.net/api/2019-06-17/jobs/e865e8bd-955d-4179-af2a-4c8d0686f1cc/workitems/JIT.Regression.JitBlue/console
This assert fails: runtime/src/coreclr/jit/emit.cpp Line 8610 in 5605bdf
After that, createdump fails this assert in libunwind:
|
Yes. Opened #64168 |
@BruceForstall if you end up bumping up the IG size for this let's make sure it is big enough for OSR too. |
@AndyAyersMS Do you have any idea what the maximum number of instructions might be for OSR? Or, put another way, what is the maximum amount bigger (in number of instructions) that an OSR prolog might be compared to a non-OSR prolog (for arm64/x64)? This issue has only occurred (AFAIK) now on arm64 due when we have very large frames that require loading large local variable constant offsets into a temp register for many initializations. I'm inclined to just double the arm64 max IG size. |
Looks like OSR is trying to load up 25 enregistered locals, each load takes 3 instructions on arm64:
and there are at least 25 other instructions in the prolog before this (and possibly a few after). So perhaps 120 instructions worth? If this is unworkable I can probably common some of the address math and squeeze this down a bit. |
I think we're ok on x64 for now, latest osr stress only has arm64 failures. |
That's for this particular test case? Where does the number "25" come from? In general, is this number capped (is there a maximum?), or can it be unbounded? |
It's limited by the number of allocatable registers (I think just int registers as we initialize FP registers outside the OS prolog). |
Actually, since we care here about the JIT prolog insGroup, it includes everything in the JIT prolog, including zero inits, moving registers to the LSRA assigned locations, etc. -- not just the OS prolog. |
Well then it might include initializing all the allocatable FP registers and all the allocatable INT registers. |
In case you're wondering -- OSR is "unusual" in that a lot more things can be live on entry than in a normal method. Anything live on entry and enregistered gets loaded up from the Tier0 frame in the OSR prolog. I suppose we could defer all of this loading but it would complicate things quite a bit. |
We require that the maximum number of prolog instructions all fit in one instruction group. Recent changes appear to have increased the number of instructions we are generating the prolog, leading to NOWAY assert on Release builds and test failure on linux-arm64. Bump up the number to avoid this problem, and leave some headroom for possible additional needs. Fixes dotnet#64162, dotnet#64793.
We require that the maximum number of prolog instructions all fit in one instruction group. Recent changes appear to have increased the number of instructions we are generating the prolog, leading to NOWAY assert on Release builds and test failure on linux-arm64. Bump up the number to avoid this problem, and leave some headroom for possible additional needs. Fixes #64162, #64793.
From outerloop (Pri1) test log: https://helix.dot.net/api/2019-06-17/jobs/e865e8bd-955d-4179-af2a-4c8d0686f1cc/workitems/JIT.Regression.JitBlue/console
This assert fails:
runtime/src/coreclr/jit/emit.cpp
Line 8610 in 5605bdf
After that, createdump fails this assert in libunwind:
runtime/src/coreclr/pal/src/libunwind/src/dwarf/Gfind_proc_info-lsb.c
Line 929 in 5605bdf
The text was updated successfully, but these errors were encountered: