This is an archive of the discontinued LLVM Phabricator instance.

[CMake] Use LLVM_RUNTIME_TARGET in runtimes
AcceptedPublic

Authored by phosek on Nov 4 2022, 11:25 AM.

Details

Reviewers
mstorsjo
mgorny
ldionne
smeenai
beanz
Group Reviewers
Restricted Project
Restricted Project
Restricted Project
Commits
rGbec8a372fc0d: [CMake] Use LLVM_TARGET_TRIPLE in runtimes
Summary

This variable is separate from LLVM_DEFAULT_TARGET_TRIPLE and
LLVM_TARGET_TRIPLE and is used to as per-target directory path.

Diff Detail

Event Timeline

phosek created this revision.Nov 4 2022, 11:25 AM
Herald added projects: Restricted Project, Restricted Project, Restricted Project. · View Herald TranscriptNov 4 2022, 11:25 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
phosek requested review of this revision.Nov 4 2022, 11:25 AM
Herald added projects: Restricted Project, Restricted Project, Restricted Project. · View Herald TranscriptNov 4 2022, 11:25 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
Herald added a reviewer: Restricted Project. · View Herald Transcript
mgorny added inline comments.Nov 4 2022, 11:43 AM
runtimes/CMakeLists.txt
167

Shouldn't it be a CACHE variable?

smeenai added inline comments.Nov 4 2022, 12:07 PM
runtimes/CMakeLists.txt
165

We were previously setting LLVM_DEFAULT_TARGET_TRIPLE as part of our configure, so this CACHE setting would never take effect. We'll now set it to the host triple, which seems potentially undesirable?

phosek updated this revision to Diff 473364.Nov 4 2022, 4:07 PM
phosek marked 2 inline comments as done.
Herald added a project: Restricted Project. · View Herald TranscriptNov 4 2022, 4:07 PM
Herald added subscribers: Restricted Project, Enna1. · View Herald Transcript
smeenai accepted this revision.Nov 4 2022, 4:25 PM

LGTM. I didn't realize the LLVM_TARGET_TRIPLE variable already existed and you were just making use of it in more places earlier.

runtimes/CMakeLists.txt
166–169

Should we error if this isn't set, instead of defaulting to the host triple? All call sites from the runtimes build should be setting a value, right?

mgorny accepted this revision.Nov 21 2022, 8:50 PM

LGTM

ldionne accepted this revision.Nov 22 2022, 6:53 AM
This revision is now accepted and ready to land.Nov 22 2022, 6:53 AM
phosek added inline comments.Nov 28 2022, 7:04 PM
runtimes/CMakeLists.txt
165

Great point, after thinking about this a bit more, I think it'd be best to drop LLVM_DEFAULT_TARGET_TRIPLE altogether and replace it with LLVM_TARGET_TRIPLE.

This revision was landed with ongoing or failed builds.Nov 28 2022, 8:08 PM
This revision was automatically updated to reflect the committed changes.

This patch seem to do a bit more than it's description implies. It makes LLVM_DEFAULT_TARGET_TRIPLE no longer an valid option on the runtimes path:

CMake Warning:
  Manually-specified variables were not used by the project:

    LLVM_DEFAULT_TARGET_TRIPLE

Is this intended? Currently LLVM_DEFAULT_TARGET_TRIPLE is the only option we actually document for changing the target triple (https://llvm.org/docs/CMake.html), so now the support options seem kind of inconsistent (though I don't fully grok the intended distinction between LLVM_DEFAULT_TARGET_TRIPLE and LLVM_TARGET_TRIPLE, which may be part of the problem).

This patch seem to do a bit more than it's description implies. It makes LLVM_DEFAULT_TARGET_TRIPLE no longer an valid option on the runtimes path:

CMake Warning:
  Manually-specified variables were not used by the project:

    LLVM_DEFAULT_TARGET_TRIPLE

Is this intended? Currently LLVM_DEFAULT_TARGET_TRIPLE is the only option we actually document for changing the target triple (https://llvm.org/docs/CMake.html), so now the support options seem kind of inconsistent (though I don't fully grok the intended distinction between LLVM_DEFAULT_TARGET_TRIPLE and LLVM_TARGET_TRIPLE, which may be part of the problem).

LLVM_DEFAULT_TARGET_TRIPLE is the default value that's used by tools like clang or llc when you don't explicitly specify --target or --triple. LLVM_TARGET_TRIPLE is the target triple we're building for. LLVM_DEFAULT_TARGET_TRIPLE is used as a the default value for LLVM_TARGET_TRIPLE but they're independent.

I couldn't come up with a use case for LLVM_DEFAULT_TARGET_TRIPLE in the runtimes build which is why I dropped it, but I'm open to revisiting that if you have other suggestions. I can also update the documentation to make sure this difference is covered.

phosek reopened this revision.Dec 30 2022, 10:33 AM
phosek updated this revision to Diff 485716.
phosek retitled this revision from [CMake] Use LLVM_TARGET_TRIPLE in runtimes to [CMake] Use LLVM_RUNTIME_TRIPLE in runtimes.
phosek edited the summary of this revision. (Show Details)
This revision is now accepted and ready to land.Dec 30 2022, 10:33 AM
phosek updated this revision to Diff 486086.Jan 3 2023, 2:22 PM

This patch seem to do a bit more than it's description implies. It makes LLVM_DEFAULT_TARGET_TRIPLE no longer an valid option on the runtimes path:

CMake Warning:
  Manually-specified variables were not used by the project:

    LLVM_DEFAULT_TARGET_TRIPLE

Is this intended? Currently LLVM_DEFAULT_TARGET_TRIPLE is the only option we actually document for changing the target triple (https://llvm.org/docs/CMake.html), so now the support options seem kind of inconsistent (though I don't fully grok the intended distinction between LLVM_DEFAULT_TARGET_TRIPLE and LLVM_TARGET_TRIPLE, which may be part of the problem).

LLVM_DEFAULT_TARGET_TRIPLE is the default value that's used by tools like clang or llc when you don't explicitly specify --target or --triple. LLVM_TARGET_TRIPLE is the target triple we're building for. LLVM_DEFAULT_TARGET_TRIPLE is used as a the default value for LLVM_TARGET_TRIPLE but they're independent.

I couldn't come up with a use case for LLVM_DEFAULT_TARGET_TRIPLE in the runtimes build which is why I dropped it, but I'm open to revisiting that if you have other suggestions. I can also update the documentation to make sure this difference is covered.

I think the point that @daltenty raises, is that if you're currently building the runtimes (by manually invoking cmake on the llvm-project/runtimes directory), you might be setting LLVM_DEFAULT_TARGET_TRIPLE which previously worked for setting it, but after this patch no longer works. My branch for llvm-mingw to make it use the per-target directory does exactly that: https://github.com/mstorsjo/llvm-mingw/commit/2cf53146bb94e0cd56b36b4c71ef09753143389f

I tried setting LLVM_TARGET_TRIPLE instead of LLVM_DEFAULT_TARGET_TRIPLE here, but that doesn't seem to work - with current git main, the only way of setting the triple for the purposes of the per-target runtime directories, is to set LLVM_DEFAULT_TARGET_TRIPLE. So in that respect, it's a public interface, and it'd at least be courteous to keep the old one working for some transition time while switching to a different way of setting it.

Curiously, for compiler-rt, it seems to infer it from CMAKE_C_COMPILER_TARGET, while libcxx/libunwind/libcxxabi seem to require it to be set via LLVM_DEFAULT_TARGET_TRIPLE.

phosek updated this revision to Diff 557409.Sep 27 2023, 10:40 AM
phosek retitled this revision from [CMake] Use LLVM_RUNTIME_TRIPLE in runtimes to [CMake] Use LLVM_RUNTIME_TARGET in runtimes.

This patch seem to do a bit more than it's description implies. It makes LLVM_DEFAULT_TARGET_TRIPLE no longer an valid option on the runtimes path:

CMake Warning:
  Manually-specified variables were not used by the project:

    LLVM_DEFAULT_TARGET_TRIPLE

Is this intended? Currently LLVM_DEFAULT_TARGET_TRIPLE is the only option we actually document for changing the target triple (https://llvm.org/docs/CMake.html), so now the support options seem kind of inconsistent (though I don't fully grok the intended distinction between LLVM_DEFAULT_TARGET_TRIPLE and LLVM_TARGET_TRIPLE, which may be part of the problem).

LLVM_DEFAULT_TARGET_TRIPLE is the default value that's used by tools like clang or llc when you don't explicitly specify --target or --triple. LLVM_TARGET_TRIPLE is the target triple we're building for. LLVM_DEFAULT_TARGET_TRIPLE is used as a the default value for LLVM_TARGET_TRIPLE but they're independent.

I couldn't come up with a use case for LLVM_DEFAULT_TARGET_TRIPLE in the runtimes build which is why I dropped it, but I'm open to revisiting that if you have other suggestions. I can also update the documentation to make sure this difference is covered.

I think the point that @daltenty raises, is that if you're currently building the runtimes (by manually invoking cmake on the llvm-project/runtimes directory), you might be setting LLVM_DEFAULT_TARGET_TRIPLE which previously worked for setting it, but after this patch no longer works. My branch for llvm-mingw to make it use the per-target directory does exactly that: https://github.com/mstorsjo/llvm-mingw/commit/2cf53146bb94e0cd56b36b4c71ef09753143389f

I tried setting LLVM_TARGET_TRIPLE instead of LLVM_DEFAULT_TARGET_TRIPLE here, but that doesn't seem to work - with current git main, the only way of setting the triple for the purposes of the per-target runtime directories, is to set LLVM_DEFAULT_TARGET_TRIPLE. So in that respect, it's a public interface, and it'd at least be courteous to keep the old one working for some transition time while switching to a different way of setting it.

Curiously, for compiler-rt, it seems to infer it from CMAKE_C_COMPILER_TARGET, while libcxx/libunwind/libcxxabi seem to require it to be set via LLVM_DEFAULT_TARGET_TRIPLE.

This should be addressed in the latest version. I plan on landing this change today unless there are any concerns as a prerequisite for D140925.

This should be addressed in the latest version.

Ok, so this now retains LLVM_DEFAULT_TARGET_TRIPLE as the external user-settable cache variable that controls this, while the internal code is refactored to use LLVM_RUNTIME_TARGET instead? And I guess it's possible to build this by just setting LLVM_RUNTIME_TARGET directly too, even if that's not a cache variable?

That seems reasonable to me. Would the next steps after that be to do an actual deprecation cycle - warning users if they're setting the old variable name and making LLVM_RUNTIME_TARGET a cache variable as well? And then after the next release (or later?), remove handling of the old variable name here?

This should be addressed in the latest version.

Ok, so this now retains LLVM_DEFAULT_TARGET_TRIPLE as the external user-settable cache variable that controls this, while the internal code is refactored to use LLVM_RUNTIME_TARGET instead? And I guess it's possible to build this by just setting LLVM_RUNTIME_TARGET directly too, even if that's not a cache variable?

Yes, that's correct.

That seems reasonable to me. Would the next steps after that be to do an actual deprecation cycle - warning users if they're setting the old variable name and making LLVM_RUNTIME_TARGET a cache variable as well? And then after the next release (or later?), remove handling of the old variable name here?

That was my plan assuming we don't want to keep support for LLVM_DEFAULT_TARGET_TRIPLE which would be my preference.

mstorsjo accepted this revision.Sep 28 2023, 12:28 PM

That seems reasonable to me. Would the next steps after that be to do an actual deprecation cycle - warning users if they're setting the old variable name and making LLVM_RUNTIME_TARGET a cache variable as well? And then after the next release (or later?), remove handling of the old variable name here?

That was my plan assuming we don't want to keep support for LLVM_DEFAULT_TARGET_TRIPLE which would be my preference.

That sounds very good to me, if given a reasonable deprecation cycle (one major release with both setups working, with warnings suggesting moving from old to new).