Uh oh!
There was an error while loading. Please reload this page.
Enable "Allocate on stack" for NAOT/R2R - #104411
Conversation
Uh oh!
There was an error while loading. Please reload this page.
ShreyasJejurkar
commented
Jul 4, 2024
Is the .NET main branch broken on CE somehow? Checking the codegen for the example, yields older code. |
EgorBo
commented
Jul 4, 2024
|
AndyAyersMS
commented
Jul 4, 2024
I'm surprised that you don't need to do anything on the runtime side to implement |
EgorBo
commented
Jul 4, 2024
CI is currently failing with: 🙂 |
Uh oh!
There was an error while loading. Please reload this page.
EgorBo
commented
Jul 5, 2024
/azp run runtime-nativeaot-outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
EgorBo
commented
Jul 5, 2024
I think this is ready, PTAL @jkotas@MichalStrehovsky@AndyAyersMS |
Uh oh!
There was an error while loading. Please reload this page.
| for (int i = 0; i < ptrsCount; i++) | ||
| gcPtrs[i] = (byte)CorInfoGCType.TYPE_GC_NONE; | ||
| uint size = type.IsValueType ? getClassSize(cls) : getHeapClassSize(cls); | ||
| new Span<byte>(gcPtrs, (int)((size + PointerSize - 1) / PointerSize)).Clear(); |
There was a problem hiding this comment.
This was copied from CoreCLR impl, it does a similar memset (see this)
Previously, getClassGClayout used InstanceFieldSize.AsInt which for ref types always return just pointer-size while we need the real size. Since it has never been used for ref-types before, it wasn't an issue.
EgorBo
commented
Jul 12, 2024
Outerloops:
|
MichalStrehovsky
commented
Jul 12, 2024
This is #104500. |
| if (attribs.Length == 0) | ||
| return true; // Assume corelib is optimized in this case |
There was a problem hiding this comment.
Adding <DebuggerSupport>true</DebuggerSupport> to the project file would make the attribute visible, but ILC has its own optimization switch so CoreLib having this attribute still doesn't necessarily imply how optimized it is.
There was a problem hiding this comment.
@MichalStrehovsky do we run runtime tests with NativeAOT in full debug mode?
There was a problem hiding this comment.
So can you tell me how to properly check it here?
There was a problem hiding this comment.
@MichalStrehovsky do we run runtime tests with NativeAOT in full debug mode?
We do have such legs, I'm not sure if they include this test too. It would be in the runtime or runtime-nativeaot-outerloop if it exists.
So can you tell me how to properly check it here?
Native AOT will use the same settings for optimizing both CoreLib and user code so enabling the attribute and looking for the attribute on Assembly.GetEntryAssembly would give the answer.
I guess I don't understand why this is looking at whether corelib is optimized. Why does that affect stack allocations in this test?
There was a problem hiding this comment.
I guess I don't understand why this is looking at whether corelib is optimized. Why does that affect stack allocations in this test?
Maybe the way we build the tests, optimization of CoreLib always matches optimization of the test?
If that's the case, all that's needed is to add <DebuggerSupport>true</DebuggerSupport> to the test project and this will work the same. It will also fail the same if there's ever mismatch between test optimization and corelib optimization.
There was a problem hiding this comment.
I guess I don't understand why this is looking at whether corelib is optimized. Why does that affect stack allocations in this test?
I am not the original author (I presume the authors no longer work in the team), but looks like the test tries to be agile and validate that nothing is stack-allocated under debug maybe? 🤷
There was a problem hiding this comment.
I am not the original author (I presume the authors no longer work in the team), but looks like the test tries to be agile and validate that nothing is stack-allocated under debug maybe?
Right, but for that one would check whether the test is optimized, not corelib. One can build the test with <Optimize>true</Optimize> and have corelib from a debug build. I assume the test would fail in that case.
There was a problem hiding this comment.
(I mean in the JIT case. It would also fail in the AOT case because I believe the test is looking at the wrong assembly.)
There was a problem hiding this comment.
I ended up removing these bits and the test is still working fine (it's always optimized due to <Optimize>true</Optimize>)
EgorBo
commented
Jul 12, 2024
/azp run runtime-nativeaot-outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
EgorBo
commented
Jul 13, 2024
/azp run runtime-coreclr runtime-nativeaot-outerloop |
|
No pipelines are associated with this pull request. |
EgorBo
commented
Jul 13, 2024
/azp run runtime-nativeaot-outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
EgorBo
commented
Jul 14, 2024
@jkotas@MichalStrehovsky can this be merged then? All nativeaot-outerloop failures are either #104862 or #104500 |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.

Closes#104350
Fixes#104337
This PR adds NAOT/R2R support for #103361
Example:
Old codegen for
Test()on NAOT (and R2R):New codegen: