[lld] check cache before real_path in loadDylib #140791
Conversation
In llvm#137649 symlink resolution was added when loading dylibs. This introduced a performance regression when linking with a large number of inputs with LC_LOAD_DYLIB commands due to the syscall overhead of realpath. Refactor the change to be closer to the original: - first check if the given path is in the cache - if not, resolve it and check again - update cache entries of both paths to point to the same dylib This mitigates the regression as we do not incur the realpath cost for every loadDylib call, only once per unique path.
|
@llvm/pr-subscribers-lld-macho Author: Richard Howell (rmaz) ChangesIn #137649 symlink resolution was added when loading dylibs. This introduced a performance regression when linking with a large number of inputs with LC_LOAD_DYLIB commands due to the syscall overhead of realpath. Refactor the change to be closer to the original:
This mitigates the regression as we do not incur the realpath cost for every loadDylib call, only once per unique path. Full diff: https://github.com/llvm/llvm-project/pull/140791.diff 1 Files Affected:
diff --git a/lld/MachO/DriverUtils.cpp b/lld/MachO/DriverUtils.cpp
index cf874018fa34b..14d60eb4cfa81 100644
--- a/lld/MachO/DriverUtils.cpp
+++ b/lld/MachO/DriverUtils.cpp
@@ -229,12 +229,7 @@ static DenseMap<CachedHashStringRef, DylibFile *> loadedDylibs;
DylibFile *macho::loadDylib(MemoryBufferRef mbref, DylibFile *umbrella,
bool isBundleLoader, bool explicitlyLinked) {
- // Frameworks can be found from different symlink paths, so resolve
- // symlinks before looking up in the dylib cache.
- SmallString<128> realPath;
- std::error_code err = fs::real_path(mbref.getBufferIdentifier(), realPath);
- CachedHashStringRef path(!err ? uniqueSaver().save(StringRef(realPath))
- : mbref.getBufferIdentifier());
+ CachedHashStringRef path(mbref.getBufferIdentifier());
DylibFile *&file = loadedDylibs[path];
if (file) {
if (explicitlyLinked)
@@ -242,6 +237,23 @@ DylibFile *macho::loadDylib(MemoryBufferRef mbref, DylibFile *umbrella,
return file;
}
+ // Frameworks can be found from different symlink paths, so resolve
+ // symlinks and look up in the dylib cache.
+ DylibFile *&realfile = file;
+ SmallString<128> realPath;
+ std::error_code err = fs::real_path(mbref.getBufferIdentifier(), realPath);
+ if (!err) {
+ CachedHashStringRef resolvedPath(uniqueSaver().save(StringRef(realPath)));
+ realfile = loadedDylibs[resolvedPath];
+ if (realfile) {
+ if (explicitlyLinked)
+ realfile->setExplicitlyLinked();
+
+ file = realfile;
+ return realfile;
+ }
+ }
+
DylibFile *newFile;
file_magic magic = identify_magic(mbref.getBuffer());
if (magic == file_magic::tapi_file) {
@@ -253,6 +265,7 @@ DylibFile *macho::loadDylib(MemoryBufferRef mbref, DylibFile *umbrella,
}
file =
make<DylibFile>(**result, umbrella, isBundleLoader, explicitlyLinked);
+ realfile = file;
// parseReexports() can recursively call loadDylib(). That's fine since
// we wrote the DylibFile we just loaded to the loadDylib cache via the
@@ -268,6 +281,7 @@ DylibFile *macho::loadDylib(MemoryBufferRef mbref, DylibFile *umbrella,
magic == file_magic::macho_executable ||
magic == file_magic::macho_bundle);
file = make<DylibFile>(mbref, umbrella, isBundleLoader, explicitlyLinked);
+ realfile = file;
// parseLoadCommands() can also recursively call loadDylib(). See comment
// in previous block for why this means we must copy `file` here.
|
|
@llvm/pr-subscribers-lld Author: Richard Howell (rmaz) ChangesIn #137649 symlink resolution was added when loading dylibs. This introduced a performance regression when linking with a large number of inputs with LC_LOAD_DYLIB commands due to the syscall overhead of realpath. Refactor the change to be closer to the original:
This mitigates the regression as we do not incur the realpath cost for every loadDylib call, only once per unique path. Full diff: https://github.com/llvm/llvm-project/pull/140791.diff 1 Files Affected:
diff --git a/lld/MachO/DriverUtils.cpp b/lld/MachO/DriverUtils.cpp
index cf874018fa34b..14d60eb4cfa81 100644
--- a/lld/MachO/DriverUtils.cpp
+++ b/lld/MachO/DriverUtils.cpp
@@ -229,12 +229,7 @@ static DenseMap<CachedHashStringRef, DylibFile *> loadedDylibs;
DylibFile *macho::loadDylib(MemoryBufferRef mbref, DylibFile *umbrella,
bool isBundleLoader, bool explicitlyLinked) {
- // Frameworks can be found from different symlink paths, so resolve
- // symlinks before looking up in the dylib cache.
- SmallString<128> realPath;
- std::error_code err = fs::real_path(mbref.getBufferIdentifier(), realPath);
- CachedHashStringRef path(!err ? uniqueSaver().save(StringRef(realPath))
- : mbref.getBufferIdentifier());
+ CachedHashStringRef path(mbref.getBufferIdentifier());
DylibFile *&file = loadedDylibs[path];
if (file) {
if (explicitlyLinked)
@@ -242,6 +237,23 @@ DylibFile *macho::loadDylib(MemoryBufferRef mbref, DylibFile *umbrella,
return file;
}
+ // Frameworks can be found from different symlink paths, so resolve
+ // symlinks and look up in the dylib cache.
+ DylibFile *&realfile = file;
+ SmallString<128> realPath;
+ std::error_code err = fs::real_path(mbref.getBufferIdentifier(), realPath);
+ if (!err) {
+ CachedHashStringRef resolvedPath(uniqueSaver().save(StringRef(realPath)));
+ realfile = loadedDylibs[resolvedPath];
+ if (realfile) {
+ if (explicitlyLinked)
+ realfile->setExplicitlyLinked();
+
+ file = realfile;
+ return realfile;
+ }
+ }
+
DylibFile *newFile;
file_magic magic = identify_magic(mbref.getBuffer());
if (magic == file_magic::tapi_file) {
@@ -253,6 +265,7 @@ DylibFile *macho::loadDylib(MemoryBufferRef mbref, DylibFile *umbrella,
}
file =
make<DylibFile>(**result, umbrella, isBundleLoader, explicitlyLinked);
+ realfile = file;
// parseReexports() can recursively call loadDylib(). That's fine since
// we wrote the DylibFile we just loaded to the loadDylib cache via the
@@ -268,6 +281,7 @@ DylibFile *macho::loadDylib(MemoryBufferRef mbref, DylibFile *umbrella,
magic == file_magic::macho_executable ||
magic == file_magic::macho_bundle);
file = make<DylibFile>(mbref, umbrella, isBundleLoader, explicitlyLinked);
+ realfile = file;
// parseLoadCommands() can also recursively call loadDylib(). See comment
// in previous block for why this means we must copy `file` here.
|
| SmallString<128> realPath; | ||
| std::error_code err = fs::real_path(mbref.getBufferIdentifier(), realPath); | ||
| if (!err) { | ||
| CachedHashStringRef resolvedPath(uniqueSaver().save(StringRef(realPath))); |
There was a problem hiding this comment.
| CachedHashStringRef resolvedPath(uniqueSaver().save(StringRef(realPath))); | |
| CachedHashStringRef resolvedPath(uniqueSaver().save(realPath.str())); |
| @@ -253,6 +265,7 @@ DylibFile *macho::loadDylib(MemoryBufferRef mbref, DylibFile *umbrella, | |||
| } | |||
| file = | |||
| make<DylibFile>(**result, umbrella, isBundleLoader, explicitlyLinked); | |||
| realfile = file; | |||
There was a problem hiding this comment.
In the common case we have
DylibFile *&file = loadedDylibs[path];
DylibFile *&realfile = file;
Then what happens on this line? It does a load and a store to the same address? I'm sure it does the right thing it just looks funny to me.
Also, if we set file later in the future, how can we make sure to not forget to also set realfile? Is there a better way of doing this?
There was a problem hiding this comment.
Then what happens on this line? It does a load and a store to the same address?
Thats what I thought would happen, yes.
Also, if we set file later in the future, how can we make sure to not forget to also set realfile? Is there a better way of doing this?
What would you suggest? Ultimately we have 2 cache pointers, that may or may not point to the same thing, and we need to update them.
There was a problem hiding this comment.
What if we just use realfile everywhere? In the case when the pointers are the same, everything works as expected. But when they are different, the first cache lookup is basically always a miss and will rely on the second resolved path lookup to find the result. In theory, it shouldn't be a huge hit, but it's still a minor regression from the current implementation. But, it makes things easier to reason about without needing to set both file and realfile?
There was a problem hiding this comment.
That would mean that we would never cache symlinks, only their resolved paths, which is the unhappy path. That would be a significant regression as a large number of load commands are symlinks (eg Foundation.framework/Foundation -> Foundation.framework/Versions/A/Foundation).
I also disagree with the idea of regressing the performance to reduce the amount of code by 2 lines.
The only alternative I can see is to do have realfile default to a nullptr and have the two setters change to:
if (realfile)
realfile = file;
Can't say I prefer it though.
There was a problem hiding this comment.
Would something like llvm::make_scope_exit([&]{ realfile = file; }) be OK to keep things organized? Would that work?
Edit: or add a single line after this if {} else {} block. I am scared that it will not be obvious there if something changes in the if {} else {} block, though.
In #137649 symlink resolution was added when loading dylibs. This introduced a performance regression when linking with a large number of inputs with LC_LOAD_DYLIB commands due to the syscall overhead of realpath.
Refactor the change to be closer to the original:
This mitigates the regression as we do not incur the realpath cost for every loadDylib call, only once per unique path.