Skip to content

Dynamic generate hwintrinsic tests #79552

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

tannergooding
Copy link
Member

@tannergooding tannergooding commented Dec 12, 2022

As per the feedback on #76642, this updates the generated HWIntrinsic tests to not be checked in and instead to be generated dynamically as part of the build.

This resolves #75791

CC. @jkotas, @stephentoub

@ghost
Copy link

ghost commented Dec 12, 2022

Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics
See info in area-owners.md if you want to be subscribed.

Issue Details

As per the feedback on #76642, this updates the generated HWIntrinsic tests to not be checked in and instead to be generated dynamically as part of the build.

CC. @jkotas, @stephentoub

Author: tannergooding
Assignees: tannergooding
Labels:

area-System.Runtime.Intrinsics

Milestone: -

Comment on lines 1 to 35
<?xml version="1.0" encoding="utf-8"?>
<Project>

<Import Project="$([MSBuild]::GetPathOfFileAbove(Directory.Build.targets, $(MSBuildThisFileDirectory)..))" />

<ItemGroup>
<ProjectReference Include="$(RepoRoot)/src/tests/Common/GenerateHWIntrinsicTests/GenerateHWIntrinsicTests_Arm.csproj" ReferenceOutputAssembly="false" />
</ItemGroup>

<PropertyGroup>
<GeneratedHWIntrinsicTestDirectory Condition="'$(GeneratedHWIntrinsicTestDirectory)' == ''">$(IntermediateOutputPath)$(MSBuildProjectName)/gen/</GeneratedHWIntrinsicTestDirectory>
<GeneratedHWIntrinsicTestListFile Condition="'$(GeneratedHWIntrinsicTestListFile)' == ''">$(GeneratedHWIntrinsicTestDirectory)GeneratedHWIntrinsicTestList.txt</GeneratedHWIntrinsicTestListFile>
</PropertyGroup>

<Target Name="ExecuteGenerateTestsScript"
Inputs="$(MSBuildAllProjects);$(RepoRoot)/src/tests/Common/GenerateHWIntrinsicTests/GenerateHWIntrinsicTests_Arm.cs"
Outputs="$(GeneratedHWIntrinsicTestListFile)"
Condition="'$(Language)' == 'C#'">
<Exec Command="$(DotNetCli) run --project $(RepoRoot)/src/tests/Common/GenerateHWIntrinsicTests/GenerateHWIntrinsicTests_Arm.csproj -c $(Configuration) -- $(MSBuildProjectName) $(MSBuildThisFileDirectory)Shared $(GeneratedHWIntrinsicTestDirectory) $(GeneratedHWIntrinsicTestListFile)" />
</Target>

<Target Name="ReadGeneratedHWIntrinsicTestListFile"
BeforeTargets="BeforeCompile;CoreCompile"
DependsOnTargets="ExecuteGenerateTestsScript"
Returns="$(GeneratedHWIntrinsicTestList)"
Condition="'$(Language)' == 'C#'">
<ReadLinesFromFile File="$(GeneratedHWIntrinsicTestListFile)">
<Output TaskParameter="Lines" ItemName="GeneratedHWIntrinsicTestList" />
</ReadLinesFromFile>
<ItemGroup>
<Compile Include="@(GeneratedHWIntrinsicTestList)" />
</ItemGroup>
</Target>

</Project>
Copy link
Member Author

@tannergooding tannergooding Dec 12, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the actual interesting "bit" of the change.

Each high level folder (Arm, General, X86) has a targets file that:

  1. Has a dependency on the relevant test generator to ensure it is built first
  2. A target that runs the test generator to ensure the necessary files exist, with relevant up to date checks to ensure it doesn't run unnecessarily
  3. A target that has to always run as part of compilation to read the list of generated tests and include them in the list of files csc should process

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The actual GenerateTests.csx was simply moved to be part of a csproj and to take a couple inputs to help filter the tests.

It's not necessarily the cleanest change, but it is by far one of the simplest. Building a source generator or otherwise refactoring things more would result in significantly more time and churn and would block the AVX-512 work until that was completed.

@AaronRobinsonMSFT
Copy link
Member

FYI @davidwrighton

@tannergooding tannergooding marked this pull request as ready for review December 13, 2022 22:00
@tannergooding
Copy link
Member Author

Should be ready for review/merging

@tannergooding
Copy link
Member Author

Ping on review here, would be nice to get this merged in so other PRs can be unblocked

@dakersnar
Copy link
Contributor

Can't type in the review section because the diff is so large 😄.

LGTM, I think this seems like a reasonable solution to the feedback. I do think this should get a review from one of the people invested in that conversation (I'll add them as suggested reviewers). @tannergooding it might be worth merging now if this is blocking other work and having those additional reviews happen post-merge (assuming we can easily revert this if there is any pushback).

Copy link
Member

@AaronRobinsonMSFT AaronRobinsonMSFT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

@dakersnar dakersnar merged commit 781fe41 into dotnet:main Dec 19, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Jan 18, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Vector128 and Vector256 General purpose DotProduct tests fail
3 participants