-
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
[RISC-V] Fix errors in crosgen2 for risc-v #97368
Conversation
A failure during crossgen2 SPC.dll `System.Diagnostics.Tracing.NativeRuntimeEventSource:LogThreadPoolWorkerThreadAdjustmentStats(double,double,double,double,double,double,double,double,double,ushort,ushort)`
@shushanhf It updats codes near LOONGARCH64. Please confirm that it doesn't break LOONGARCH64. And I think this PR can help you to update crossgen2 for LOONGARCH64. |
Diff results for #97368Throughput diffsThroughput diffs for windows/x86 ran on windows/x86Overall (+0.00% to +0.01%)
MinOpts (+0.01%)
FullOpts (+0.00% to +0.01%)
Details here |
I've looked at the changes to the crossgen2 and vm codebase, and they appear to be reasonable. I'm not marking this as code reviewed, as I have not reviewed any of the JIT changes, or seen a review from a JIT expert with review privileges. |
With this change (and a small tweak in perfmap), #96941 also gets unblocked. 👍 |
We had published the crossgen2 within our SDK8.0-LoongArch64. |
src/coreclr/jit/lsra.cpp
Outdated
#ifdef TARGET_RISCV64 | ||
if (isFloatRegType(type) && genIsValidIntReg(treeNode->GetRegNum())) | ||
{ | ||
type = (type == TYP_FLOAT) ? TYP_INT : TYP_LONG; | ||
} | ||
#endif // TARGET_RISCV64 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In what cases do you have these mismatches in the RISC-V backend? Why can you not get rid of them? (For example by inserting GT_BITCAST
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR introduces many RISCV ifdefs in general code because of the mismatch. It would be preferable to avoid it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When there are too many float arguments to allocate with 8 float argument registers, in RISCV it uses available integer argument registers. So there are mismatches which have float type and integer registers. Could you please share better solutions?
Sorry for making not good enough codes. When I saw errors, I think I tend to focus on fixing errors in RISCV and trying to find easy and simple ways for only RISC-V because of my lack of .NET runtime understanding and developing competency. I am so sorry. And thank you for your help.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No worries, let's try to see if we can avoid them. The idea would be to have lowering insert GT_BITCAST
when these mismatches happen. In fact, you can already see that Lowering:LowerFloatArg
already has this logic to handle some other cases. Can you generalize Lowering::LowerArg
so that it calls LowerFloatArg
for these new cases? In the end you would have PUTARG_REG<integer register>(BITCAST<TYP_INT>(TYP_FLOAT node))
, instead of the current PUTARG_REG<integer register>(TYP_FLOAT node)
that I am assuming that you end up with.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your comment. I will try as you told.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated mismatch cases based on your comment. I hope it is better. If I misunderstand your comment or it has any problem, please let me know. I will fix it. Thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great to me.
@shushanhf can you please check if LA64 is able to use the same fix so we can remove LA64 specific handling for unspilling as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I will check it.
We had some patches in our local runtime to release LoongArch64's SDK8.0 and we will push them after the Chinese Spring Festival.
The SDK6.0 and SDK8.0 supporting R2R is OK for LA64, the Intrinsic feature had been finished and is ready to release after the LoongArch64's Instrinsic API merged.
BTW, I think we will push lots of codes during the 2024, liking improving the R2R, supporiting intrinsic and Native-AOT, pushing the mono and some other optimization.
The mono for Unity3D had been finished and the Unity3D game is running on the LoongArch64 linux.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@shushanhf can you please check if LA64 is able to use the same fix so we can remove LA64 specific handling for unspilling as well?
Thanks very much, I think this is OK for LA64.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@shushanhf Thank you for the check. I include a commit for LA64. Thank you.
This reverts commit 381858c.
@jakobbotsch I am really appreciate for your help and kind comments. Thank you so much. @davidwrighton @jakobbotsch reviewed JIT changes and approved. Could you review the other changes and merge if it is good? |
Fixed some errors in crossgen2 compiling System.Private.CoreLib.dll and running helloworld with compiled SPC.dll
Crossgen2 for risc-v still has many bugs to be fixed. Actually, CoreCLR tests with crossgen2 are not passed yet.
Part of #84834
cc @wscho77 @HJLeee @JongHeonChoi @gbalykov @ashaurtaev @tomeksowi @sirntar @yurai007 @Bajtazar