Add dir.props files to hardware intrinsics test directories to control test env variables #15637
Conversation
…l test env variables Fixes ##15618
| <CLRTestBatchPreCommands> | ||
| <
There was a problem hiding this comment.
I don't think we want to always disable AVX here.
Instead, I think we want to test the following scenarios:
- SSE2 Enabled, higher ISAs disabled (default since SSE2 is required by RyuJIT)
- SSE41 Enabled, higher ISAs disabled (some of the helper functions should use INSERTPD, BLENDPD, etc)
- AVX Enabled, higher ISAs disabled (for VEX encoding path, some helper functions should use VBROADCAST, etc)
- other ISA Enabled, higher ISAs disabled (for when helper functions use other newer/better instructions)
There was a problem hiding this comment.
I don't think we want to always disable AVX here.
IMO we need to create a comprehensive testing plan for all Hardware Intrinsic where part of it should comprise setting of environment switches for group of tests. Anyway we are going to face combinatorial bomb here. It is related to #15490
There was a problem hiding this comment.
I have unsuccessfully looked for solution to the following problem: how to run same group of tests each time with different environment settings?
This could be useful for example in case of all Sse ... Sse42 intrinsics which in majority of cases can be promoted to AVX/AVX2 and AVX512 codegen and we should run the tests with SSE CodeGen enabled, AVX CodeGen enabled and SSE disabled etc etc
Any ideas?
There was a problem hiding this comment.
The simplest approach would be to update the netci.groovy script to have new jobs for the required environments (I believe jitStressModeScenarios is used for this, but I am not positive).
A less expensive approach (not requiring 4 new jobs that run in the outer loop) would be to update the test wrapper, JIT.HardwareIntrinsics.XUnitWrapper, to run just the hardware intrinsic tests with each configuration setting (the wrapper currently configures the environment and calls the generated exe for each test, so it is a logical place to put this logic).
There was a problem hiding this comment.
Not sure if there is any infrastructure preference on one vs the other (or some other approach), however.
There was a problem hiding this comment.
The simplest approach would be to update the netci.groovy script to have new jobs for the required environments
Agree.
There was a problem hiding this comment.
OK I will try both and we can verify than by running them in CI which is the best solution.
|
@4creators, can this be closed? I think we went with the other solution.... |
|
Yes, you are right. |
Fixes ##15618