Move JIT/HardwareIntrinsics tests to run in Pri1

[jkoritzinsky]

These tests take a very long time to build on CI (I've seen upwards of 10 minutes) because they generate millions of lines of test code and then build it, pegging the IO of the machine.

As far as I understand, most of the interesting cases only happen on outerloop runs (primarily in the jitstress-isas- pipelines), which already run all pri0 and pri1 tests. As a result, I'd like to move these tests out to Pri1 to help speed up CI for those of us that don't work on these tests.

We can also add another pipeline that runs the standard CI test modes with just these tests that triggers on a smaller subset of directories if we feel that we want said additional coverage.

[Copilot]

Pull Request Overview

This PR sets a default test priority for all hardware intrinsics tests by adding a CLRTestPriority property to the directory-level build configuration.

• Adds CLRTestPriority property set to 1 in the Directory.Build.props file for hardware intrinsics tests

[khushal1996]

As long as CI runs these tests, I think it is okay to move them to pri1. Because they visibly do take up lot of time during test build.

[jkoritzinsky]

Not nearly enough of a sample size, but this PR took 12 minutes to build the Pri0 tests, whereas #121078 took about 24.75 minutes. This sort of differential makes it much more viable for us to make further changes to improve our test build over time.

[MichalStrehovsky]

If we're doing this (not entirely opposed), we can also drop JIT/HardwareIntrinsics from here, since it becomes a no-op:

runtime/eng/pipelines/runtime.yml

Line 607 in 25800e6

testBuildArgs: 'nativeaot tree ";nativeaot;Loader;Interop;JIT/HardwareIntrinsics;" /p:BuildNativeAotFrameworkObjects=true'

The reason we selectively ran this here is because JIT changes in HW intrinsics regularly broke native AOT outerloops.

My request to the JIT team would be to run both coreclr outerloop and native AOT outerloop on HW intrinsic changes after we stop running them as Pri-0.

[tannergooding]

Seems fine to me. It is indeed much less important now that things have been mostly stable for several years.

Impactful PRs are typically running outerloop and jitstress already.

[JulieLeeMSFT]

CC @dotnet/jit-contrib.

[EgorBo]

Fine to me, but we need to make sure to trigger them for any SIMD related change in the JIT, SIMD changes are one of the most popular sources of outerloop asserts/bugs

[janvorli]

Sounds good too me. The number of these tests is actually about 1/2 of all pri1 tests, so I assume this will also save significant runtime time too.

[khushal1996]

@tannergooding @MichalStrehovsky Is it possible to run all configurations on Pri1 test for these tests as we did for Pri0? I was worried about the coverage we will get on Pri1 tests.

@EgorBo Is there a way we can trigger these tests on CI with a keyword?

[jkoritzinsky]

@khushal1996 the runtime-coreclr outerloop pipeline should cover the same platforms that the runtime pipeline covers (if not more).

[AndyAyersMS]

Our partners like Arm and Intel need to run these tests and now they can't trigger them on their own. Is there some way to fix this?

[jkoritzinsky]

@AndyAyersMS I can add a pipeline that auto-triggers these tests (and only these ones) on JIT changes. Would that work?

[AndyAyersMS]

@AndyAyersMS I can add a pipeline that auto-triggers these tests (and only these ones) on JIT changes. Would that work?

Jit changes plus any changes to these tests? Last I knew Arm folks were working on refactoring a bunch of the tests they had added.

[jkoritzinsky]

Sounds good! I'll add the pipeline definition to this PR and ping First Responders to add the pipeline.

[jkoritzinsky]

@AndyAyersMS I've added a pipeline definition in 6ce9d04. Let me know if the set of path triggers looks good to you.

[AndyAyersMS]

@AndyAyersMS I've added a pipeline definition in 6ce9d04. Let me know if the set of path triggers looks good to you.

That looks good to me but I don't typically work on that stuff.

@tannergooding anything else we should include?

[tannergooding]

That looks reasonable.

We could probably restrict it even more if desired. Really it's if the hwintrinsic* files are touched or one lower/lsra/emit (which aren't touched super frequently otherwise).

We're likely not going to catch anything from just general changes to gentree, morph, etc and the things that are broadly impacting end up running outerloop anyways.

But up to y'all if we want it to be more or less fine grained.

[jkoritzinsky]

I'd rather start coarser and you all can refine it over time.

[jkoritzinsky]

/ba-g dev innerloop msbuild timeout unrelated. This change doesn't touch product code or unmanaged code and that leg only touches unmanaged code (and died while building product code, not test code).