Disable hugeexpr1 test under JitStress modes#8830
Disable hugeexpr1 test under JitStress modes#8830RussKeldorph merged 1 commit intodotnet:masterfrom RussKeldorph:hugeexprx86
Conversation
|
@dotnet-bot test Windows_NT x86 Checked jitstress2 |
|
@pgavlin PTAL |
| <Optimize>True</Optimize> | ||
| </PropertyGroup> | ||
| <PropertyGroup> | ||
| <JitOptimizationSensitive>true</JitOptimizationSensitive> |
There was a problem hiding this comment.
You can make this <JitOptimizationSensitive Condition="'$(Platform)' == 'x86'">true</JitOptimizationSensitive> in order to disable this for x86 only.
There was a problem hiding this comment.
Yes, but that assumes that the build architecture matches the execution architecture. This has caused confusion in the past since we don't support end-to-end test build+run on all platforms. Like #6680. In this case, you might get away with it if people only use x86 builds to test 32-bit platforms, but the reward doesn't justify the risk to me. Do you still think it's worth changing?
There was a problem hiding this comment.
Do you still think it's worth changing?
Absolutely. We should not be a build targeted at architecture X on architecture Y; we should instead be cross-compiling as appropriate.
There was a problem hiding this comment.
Ok, I don't have a strong opinion. Deferring to yours. PTAL.
This test runs out of memory on x86 when its huge expressions combine with STRESS_CLONE_EXPR. In this case, the "OptimizationSensitive" label isn't ideal, but the meaning is what we need: don't run this under JitStress modes. This is disabled at build time for x86, which means that if x64-built tests are run on other architectures, e.g. ARM or ARM64, this change won't take effect.
|
@dotnet-bot test Windows_NT x86 Checked jitstress2 |
Disable hugeexpr1 test under JitStress modes Commit migrated from dotnet/coreclr@ee20dca
This test runs out of memory on x86 when its huge expressions combine with
STRESS_CLONE_EXPR. In this case, the "OptimizationSensitive" label isn't ideal,
but the meaning is what we need--don't run this under JitStress modes.
Unfortunately, we don't have a good way to disable this only when x86 is
running with JitStress, so we lose other architectures under JitStress as well.