Skip to content
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

Align LA64 targetpacks with RV64 #102628

Closed
wants to merge 13 commits into from
Closed

Conversation

am11
Copy link
Member

@am11 am11 commented May 23, 2024

Also consolidates <NativeAotSupported definitions.

@dotnet-policy-service dotnet-policy-service bot added the community-contribution Indicates that the PR has been added by a community member label May 23, 2024
@am11 am11 added the arch-riscv Related to the RISC-V architecture label May 23, 2024
@am11 am11 marked this pull request as ready for review May 24, 2024 00:12
Copy link
Contributor

@shushanhf shushanhf left a comment

Choose a reason for hiding this comment

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

LGTM for LoongArch64.

Thanks very much!

eng/Subsets.props Outdated Show resolved Hide resolved
src/coreclr/tools/aot/crossgen2/crossgen2_publish.csproj Outdated Show resolved Hide resolved
@gbalykov
Copy link
Member

cc @dotnet/samsung

Copy link
Member

@gbalykov gbalykov left a comment

Choose a reason for hiding this comment

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

Looks good to me

@am11
Copy link
Member Author

am11 commented May 29, 2024

@MichalStrehovsky, @filipnavara, with #102760 merged the build error is fixed here. This is now publishing linux-arm crossgen2 as an AOT app (instead of R2R), bringing it to the same arm64,x64 plan.

@am11 am11 requested a review from jkoritzinsky May 31, 2024 08:04
@@ -121,7 +121,8 @@
<!-- CLR NativeAot only builds in a subset of the matrix -->
<_NativeAotSupportedOS Condition="'$(TargetOS)' == 'windows' or '$(TargetOS)' == 'linux' or '$(TargetOS)' == 'osx' or '$(TargetOS)' == 'maccatalyst' or '$(TargetOS)' == 'iossimulator' or '$(TargetOS)' == 'ios' or '$(TargetOS)' == 'tvossimulator' or '$(TargetOS)' == 'tvos' or '$(TargetOS)' == 'freebsd'">true</_NativeAotSupportedOS>
<_NativeAotSupportedArch Condition="'$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64' or '$(TargetArchitecture)' == 'arm' or ('$(TargetOS)' == 'windows' and '$(TargetArchitecture)' == 'x86')">true</_NativeAotSupportedArch>
<NativeAotSupported Condition="'$(_NativeAotSupportedOS)' == 'true' and $(_NativeAotSupportedArch) == 'true'">true</NativeAotSupported>
<NativeAotSupported Condition="'$(_NativeAotSupportedOS)' == 'true' and '$(_NativeAotSupportedArch)' == 'true'">true</NativeAotSupported>
<NativeAotCanExecuteOnHost Condition="'$(NativeAotSupported)' == 'true' and ('$(CrossBuild)' != 'true' or '$(TargetOS)' == '$(HostOS)')">true</NativeAotCanExecuteOnHost>
Copy link
Member

Choose a reason for hiding this comment

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

Why do we need '$(CrossBuild)' != 'true' in the condition? I would expect '$(TargetOS)' == '$(HostOS)' to be enough.

Copy link
Member Author

Choose a reason for hiding this comment

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

This part of the condition was adapted from main

<!-- Publish crossgen2 as a single-file app on native-OS builds. Cross-OS NativeAOT compilation is not supported yet -->
<NativeAotSupported Condition="'$(CrossBuild)' == 'true' and '$(TargetOS)' != '$(HostOS)'">false</NativeAotSupported>

e.g. x64 binary running on arm64 OS is supported (as long as the host and target OS were same).

Copy link
Member

@jkotas jkotas Jun 2, 2024

Choose a reason for hiding this comment

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

x64 binary running on arm64 OS is supported (as long as the host and target OS were same).

This is situation should be covered by '$(TargetOS)' != '$(HostOS)' condition. I do not understand why we also check for CrossBuild in the condition.

@@ -121,7 +121,8 @@
<!-- CLR NativeAot only builds in a subset of the matrix -->
<_NativeAotSupportedOS Condition="'$(TargetOS)' == 'windows' or '$(TargetOS)' == 'linux' or '$(TargetOS)' == 'osx' or '$(TargetOS)' == 'maccatalyst' or '$(TargetOS)' == 'iossimulator' or '$(TargetOS)' == 'ios' or '$(TargetOS)' == 'tvossimulator' or '$(TargetOS)' == 'tvos' or '$(TargetOS)' == 'freebsd'">true</_NativeAotSupportedOS>
<_NativeAotSupportedArch Condition="'$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64' or '$(TargetArchitecture)' == 'arm' or ('$(TargetOS)' == 'windows' and '$(TargetArchitecture)' == 'x86')">true</_NativeAotSupportedArch>
<NativeAotSupported Condition="'$(_NativeAotSupportedOS)' == 'true' and $(_NativeAotSupportedArch) == 'true'">true</NativeAotSupported>
<NativeAotSupported Condition="'$(_NativeAotSupportedOS)' == 'true' and '$(_NativeAotSupportedArch)' == 'true'">true</NativeAotSupported>
Copy link
Member

Choose a reason for hiding this comment

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

https://github.com/dotnet/runtime/blob/main/src/native/managed/compile-native.proj#L18-L28 is another place that checks for whether it is possible to use native AOT to produce binaries compiler by the repo. Can we use this property there as well?

@@ -121,7 +121,8 @@
<!-- CLR NativeAot only builds in a subset of the matrix -->
<_NativeAotSupportedOS Condition="'$(TargetOS)' == 'windows' or '$(TargetOS)' == 'linux' or '$(TargetOS)' == 'osx' or '$(TargetOS)' == 'maccatalyst' or '$(TargetOS)' == 'iossimulator' or '$(TargetOS)' == 'ios' or '$(TargetOS)' == 'tvossimulator' or '$(TargetOS)' == 'tvos' or '$(TargetOS)' == 'freebsd'">true</_NativeAotSupportedOS>
<_NativeAotSupportedArch Condition="'$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64' or '$(TargetArchitecture)' == 'arm' or ('$(TargetOS)' == 'windows' and '$(TargetArchitecture)' == 'x86')">true</_NativeAotSupportedArch>
<NativeAotSupported Condition="'$(_NativeAotSupportedOS)' == 'true' and $(_NativeAotSupportedArch) == 'true'">true</NativeAotSupported>
<NativeAotSupported Condition="'$(_NativeAotSupportedOS)' == 'true' and '$(_NativeAotSupportedArch)' == 'true'">true</NativeAotSupported>
<NativeAotCanExecuteOnHost Condition="'$(NativeAotSupported)' == 'true' and ('$(CrossBuild)' != 'true' or '$(TargetOS)' == '$(HostOS)')">true</NativeAotCanExecuteOnHost>
Copy link
Member

Choose a reason for hiding this comment

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

I am not sure whether NativeAotCanExecuteOnHost is the right name for this property. We always have ilc that can execute on host for all host OSes. The problem is that we do not always have a working host/target build environment.

Would something like UseNativeAotForComponents be a better name?

<SupportsNativeAotComponents Condition="'$(SupportsNativeAotComponents)' == '' and ('$(TargetsWindows)' == 'true' or '$(TargetsOSX)' == 'true' or ('$(TargetsLinux)' == 'true' and '$(TargetsAndroid)' != 'true' and '$(TargetsLinuxMusl)' != 'true'))">true</SupportsNativeAotComponents>
<SupportsNativeAotComponents Condition="'$(SupportsNativeAotComponents)' == ''">false</SupportsNativeAotComponents>
</PropertyGroup>

<!-- some special kinds of runtime builds need extra NativeAOT flags -->
<PropertyGroup>
<SysRoot Condition="'$(CrossBuild)' == 'true' and '$(HostOS)' != 'windows'">$(ROOTFS_DIR)</SysRoot>
Copy link
Member Author

Choose a reason for hiding this comment

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

These SysRoot setup can also be brought to the same plan as ILCompiler.csproj and crossgen2.csproj (better deduplicate all three using init-compiler.sh thingy). I have a feeling it will take some digging which is why @lambdageek chose this approach, but worth a try (in a follow-up PR). 🙂

@MichalStrehovsky
Copy link
Member

am11 requested review from jkoritzinsky, jkotas and MichalStrehovsky 3 days ago

I think it would help reviewing if you could split off the native AOT change to a separate PR. I don't know about target packs or RV64 and cannot review or sign off on that.

I (and probably others) often skim commit histories and PRs to see what's going on and skip stuff with titles that are not related to my areas - a PR named "Align LA64 targetpacks" that spends most lines of the diff on something unrelated breaks such workflows.

@am11 am11 closed this Jun 3, 2024
@am11
Copy link
Member Author

am11 commented Jun 3, 2024

@MichalStrehovsky, the PR description has the line and if PR name was the issue, you or @jkotas could have told a bit earlier without going through the cycles of feedback and it would have saved both some time.

@MichalStrehovsky
Copy link
Member

@MichalStrehovsky, the PR description has the line and if PR name was the issue, you or @jkotas could have told a bit earlier without going through the cycles of feedback and it would have saved both some time.

Sorry, it was not clear who would be responsible for getting this merged since it touched multiple things owned/worked on by different teams. I often comment on PRs without an intention of taking the full responsibility of merging it - whoever merged it is the one who's ultimately responsible even if it was authored by you. It was not clear to me who could merge a PR in this shape (I guess Jan often gets to volunteer himself for these, but I don't like dumping all work on Jan). Since you asked me specifically to take a look, my feedback is really that I won't take responsibility for targeting pack changes and we're going to be blocked on finding whoever is qualified (I don't know who), unless the native AOT change is separated out.

@jkotas
Copy link
Member

jkotas commented Jun 3, 2024

I know that it is tempting to make multiple somewhat unrelated change in the same PR. I have done it myself many times, and sometimes had to revert it or split into multiple PRs to make review and approval easier.

@am11 Please take @MichalStrehovsky comment only as a suggestion. If you prefer to keep both changes in one PR, that's ok - it is still manageable. We appreciate your contributions.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-loongarch64 arch-riscv Related to the RISC-V architecture area-crossgen2-coreclr community-contribution Indicates that the PR has been added by a community member
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants