Arm64: Align methods containing loops to 32B #59828
Conversation
ghost
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT Issue DetailsFrom Arm Neoverse N1 Software Optimization Guide it is beneficial to align methods at 32B boundary. This will further work well when we start loop alignment at 32B boundaries.
As a continuation of #2249, align bigger methods having loops to 32B alignment boundary.
|
|
@dotnet/jit-contrib , @jkotas |
@kunalspathak Have we ever seen an overestimation issue on Arm64? I thought we shouldn't given that all the instructions have the same size. |
That's right, but the assert we had was little lose. I updated it for Arm64 to make sure that the memory consumed size and the code size matches. |
| #ifdef TARGET_XARCH | ||
| // For x64/x86, align methods that are "optimizations enabled" to 32 byte boundaries if | ||
| #if defined(TARGET_XARCH) || defined(TARGET_ARM64) | ||
| // For x64/x86/arm64, align methods that are "optimizations enabled" to 32 byte boundaries if |
There was a problem hiding this comment.
Btw, does it make any sense to align methods without loops in terms of performance? I just wonder if we should also enable it for "hot" methods with PGO/callcount data
There was a problem hiding this comment.
We could do that but we need to validate if it pays off. Remember that aligning methods to higher boundary is not free and introduces memory fragmentation.
Correct, that is a separate work item. |
|
Failures unrelated. |
5 participants
From Arm Neoverse N1 Software Optimization Guide it is beneficial to align methods at 32B boundary. This will further work well when we start loop alignment at 32B boundaries.
As a continuation of #2249, align bigger methods having loops to 32B alignment boundary.
idCodeSize()before printing the instruction which was necessary because the callers never pass theszand it