This is an archive of the discontinued LLVM Phabricator instance.

[Driver][Windows] Support per-target runtimes dir layout for profile instr generate
ClosedPublic

Authored by zero9178 on Feb 12 2021, 3:24 PM.

Details

Summary

When targeting a MSVC triple, --dependant-libs with the name of the clang runtime library for profiling is added to the command line args. In it's current implementations clang_rt.profile-<ARCH> is chosen as the name. When building a distribution using LLVM_ENABLE_PER_TARGET_RUNTIME_DIR this fails, due to the runtime file names not having an architecture suffix in the filename.

This patch refactors getCompilerRTBasename to first try and find the version without the architecture suffix before then falling back to using the architecture suffix. Since no callers have explicitly used the AddArch parameter, and the correct choice is now autodetected by default it has also been removed.

Diff Detail

Event Timeline

zero9178 requested review of this revision.Feb 12 2021, 3:24 PM
zero9178 created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptFeb 12 2021, 3:24 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript

Friendly bump :)

rnk added inline comments.Feb 23 2021, 9:50 AM
clang/lib/Driver/ToolChains/Clang.cpp
797 ↗(On Diff #323487)

Is it possible to fix the problem in getCompilerRTBasename instead? I see 6-ish instances of this code pattern that need the same fix. It will require a small bit of refactoring to getCompilerRT.

zero9178 updated this revision to Diff 325868.Feb 23 2021, 12:07 PM

Refactored getCompilerRTBasename. It now simply refers to getCompilerRT, which gathers a full path to the specified runtime library. getCompilerRTBasename then simply returns only the filename component. The previous contents of getCompilerRTBasename have been refactored into a static function used by getCompilerRT. Only users of either of the two functions has been in clang-cl specific code and besides getCompilerRT, the AddArch parameter has never been explicitly specified. As it is now autodetected I think it makes sense to remove the parameter off of getCompilerRTBasename altogether as well.

rnk accepted this revision.Feb 23 2021, 12:31 PM

lgtm

Thanks!

This revision is now accepted and ready to land.Feb 23 2021, 12:31 PM
This revision was landed with ongoing or failed builds.Feb 23 2021, 1:35 PM
This revision was automatically updated to reflect the committed changes.
thakis added a subscriber: thakis.Feb 23 2021, 5:38 PM

This broke check-clang on all platforms, e.g. here:

http://45.33.8.238/linux/40161/step_7.txt
http://45.33.8.238/macm1/4018/step_6.txt
http://45.33.8.238/win/33805/step_7.txt

Please run tests before committing.

(It also breaks check-clang in a local cmake build. The official llvm buildbot seems to be down atm, so I can't check if llvm's regular bots are all red, but I'd guess so.)

zero9178 updated this revision to Diff 326022.Feb 24 2021, 1:44 AM

Undid refactoring of getCompilerRTBasename. Previous diffs introduced a new internal function that built the basename. In that version getCompilerRTBasename simply called getCompilerRT and extracted the filename component.

This lead to issues as Toolchains such as Baremetal override getCompilerRTBasename to provide a different basename then default.

This diff now instead changes the default implementation of getCompilerRTBasename to also auto detect whether an architecture suffix should be used or not. Therefore callers of getCompilerRTBasename can rely on it picking the right filenames as well. getCompilerRT still calls into getCompilerRTBasename to get the filename, allowing Toolchains to override the virtual function.

There is now sadly a bit of repetition as both getCompilerRT and getCompilerRTBasename have to look through the library path but this should not cause any issues I believe.

Sorry for the inconvenience and the test failure.

zero9178 reopened this revision.Feb 24 2021, 1:44 AM
This revision is now accepted and ready to land.Feb 24 2021, 1:44 AM
zero9178 requested review of this revision.Feb 24 2021, 3:01 AM

I think this change, while functionality fixing the same as my previous diff, but also fixing the test failure, does deviate a bit from the original review, so I'd like it to be reviewed again if that isn't a problem.

zero9178 edited the summary of this revision. (Show Details)Feb 24 2021, 3:03 AM
zero9178 edited the summary of this revision. (Show Details)Feb 24 2021, 4:04 AM
rnk added inline comments.Feb 24 2021, 12:11 PM
clang/lib/Driver/ToolChain.cpp
441–443

This is the same as TT, right? Please use TT here or remove TT and use Triple across this function. I guess I lean towards keeping TT, but it's up to you.

466–467

This does twice as many stat syscalls as we need. That seems worth optimizing. First, in getCompilerRTBasename, we search the library path, we return a result, and then we search it again here. I think the nicest solution is probably to have one shared implementation that takes a boolean and returns the full path or the basename.

zero9178 updated this revision to Diff 326178.Feb 24 2021, 12:26 PM

Addressed one of the reviewer requests and also uploaded additional files part of the patch that were accidently left out.

zero9178 marked an inline comment as done.Feb 24 2021, 12:31 PM
zero9178 added inline comments.
clang/lib/Driver/ToolChain.cpp
466–467

Refactoring the current implementation out of getCompilerRTBasename is currently not possible as that would break the BareMetal toolchain as it overrides getCompilerRTBasename to build up a different scheme for it's runtime libraries. Not calling getCompilerRTBasename is what caused the test failure previously.

Unless you mean that I should add an optional boolean operand to getCompilerRTBasename that would get either the absolute path if possible or always return a relative path? That could work and would change getCompilerRT to not go through the library path but to instead check if that path is absolute and return if it is already.

rnk added inline comments.Feb 24 2021, 1:15 PM
clang/lib/Driver/ToolChain.cpp
466–467

I see, good point. I'd prefer to avoid extra boolean parameters when possible. My next best idea is to separate getCompilerRTBasename into two methods, one public non-virtual, and one protected virtual (getCompilerRTBasenameImpl? ech) to allow baremetal to override. The public one would do the obvious thing of returning sys::fs::filename of getCompilerRT. The protected one would retain the current implementation, and we'd update the bare metal toolchains to override the protected one.

We have prior history of doing excessive amounts of Linux Distro detection (D87187), which is why I'm being a bit fussy about the stat calls.

zero9178 updated this revision to Diff 326200.Feb 24 2021, 2:02 PM

Avoid going through the library directories, checking for the existence of a runtime library, twice by having getCompilerRTBasename call getCompilerRT and simply extract the filename component. To allow other ToolChains to override the names of runtime libraries, getCompilerRT now calls the virtual function buildCompilerRTBasename. This is used by the BareMetal toolchain.

I chose the name buildCompilerRTBasename as the call chain getCompilerRTBasename -> getCompilerRT -> getCompilerRTBasenameImpl would be a bit confusing. I am not too attached to the name though if better suggestions come along.

rnk accepted this revision.Feb 24 2021, 2:30 PM

lgtm

This revision is now accepted and ready to land.Feb 24 2021, 2:30 PM
This revision was landed with ongoing or failed builds.Feb 24 2021, 2:40 PM
This revision was automatically updated to reflect the committed changes.