Looks fine to me, I have no experience with AIX but I don't see a problem with this fix.

Hmm. This level of performance hit is not great - it means I will probably have to carry an internal patch to disable if we don't expose a compile time define or option.

LGTM, I would change P to nullptr, unless there is a good reason to check the symbol there.

ACK. When I branch - do I need to do anything in main or just leave it? I wish we could employ this model everywhere I guess :)

In D155579#4509952, @mstorsjo wrote:

@thieta IIRC you had a usecase where you scan through large numbers of files with LLVM code somewhere. Are you able to take this for a spin to make sure it doesn't affect the performance of your usecase too much?

Thanks for doing this!

Clarify release note even further

Add example to release notes

• Split the relative patch to this diff https://reviews.llvm.org/D155268
• Added some comments in both Clang and LLD
• Fixed some code style.
• Removed stray changes.

C/R fixes

Switch to prepend paths

This seems to work fine now and have tests. Next up would be to add some dependent-lib statements in various places. Please review this and let me know if there is something else that should be fixed here.

Added tests and rebased

Removed the early exit to behave similar to ld.lld, fixed the tests so they work with this behavior and then I tested all on linux and windows and it seems to work correctly! I think this is good to land.

In D155047#4493461, @hans wrote:

By the way, do we have a github issue tracking the whole https://discourse.llvm.org/t/improve-autolinking-of-compiler-rt-and-libc-on-windows-with-lld-link/71392/ situation? If so it would be nice to reference it in the commit.

In D155047#4492920, @hans wrote:

Seems handy to me. We could also add this kind of info to the /verbose output, but having a separate option is probably more convenient.

Yes, I can do that, but I rather wait for @balazske to also approve this.

Looks fine to me.

Thanks for reminding me - I have posted a summary in discourse: https://discourse.llvm.org/t/improve-autolinking-of-compiler-rt-and-libc-on-windows-with-lld-link/71392

Thanks!!

I implemented a much nicer and easier method to just find the following three paths:

Implemented much simpler method

rebase

In D151460#4372763, @mib wrote:

Can you add this commit hash to the .git-blame-ignore-revs file so it doesn't show up in the git history

Thanks for doing this! Going to assume you ran the tests and it worked :)

In D151385#4371979, @tstellar wrote:

In D151385#4371866, @thieta wrote:

Looks fine to me. But I am unsure if we need to have the toolchain file checked into LLVM. Wouldn't that be up to the person cross-compiling? Going to be hard to assume stuff there?

I wanted to add cross-compile support so that we could build 'official' binaries using GitHub actions for other arches besides x86_64. For this scenario, I think it makes sense to have the toolchain file somewhere in tree, so that it is easy to reproduce the builds. This specific file works with a container image that I created with all the necessary cross-libs, which I would also like to put in tree somewhere.

Looks fine to me. But I am unsure if we need to have the toolchain file checked into LLVM. Wouldn't that be up to the person cross-compiling? Going to be hard to assume stuff there?

In D151188#4368335, @hans wrote:

I think we should aim for this to work out of the box:

Can we land this now? It's the one outstanding diff for closing out this reformat.

rebase

Rebase

Regarding the target handling, what's your opinion on introducing a new option (for example /target:) with the default value being the host target (that is the same behavior that's used by Clang)?

In D151188#4367621, @hans wrote:

The target handling, which seems to be the tricky part, is only needed for LLVM_ENABLE_PER_TARGET_RUNTIME_DIR builds, right? And as far as I know that's not used on Windows, so maybe it's not needed?

Hi everyone, and thanks for your input. My goal with this patch is to let lld-link find the rest of the files from the toolchain without teaching every build system in the world extra logic. I have thought about the different ways to handle this, and this one seemed the least complicated, to be honest. If we wanted to directly re-use the clang driver logic with clang -link or similar - we would have to teach the build systems to call clang instead of lld-link, we would have to teach it to pass --target to that, or we would have to parse the machine information out of the object files in clang as well (non-starter I think).

In D151188#4364270, @hans wrote:

I also only looked briefly, but it seems like this assumes LLVM_ENABLE_PER_TARGET_RUNTIME_DIR builds? I think that's still off by default on Windows, so maybe it would be enough to start with supporting the non-per-target-runtime-dir case, or we should aim to support both cases.

In D151188#4363612, @mstorsjo wrote:

I believe this is closely related to what D150981 does too - please have a look at that if it helps something here.

Oh make sure you run black to check for formatting changes. We don't have the CI hooked up yet.

Nice QoL fix here! Thanks!

Hi! This is the first draft of what we discussed at EuroLLVM - to let LLD find the runtime and lib dir to integrate sanitizers easier and libc++ on Windows.

Rebase

rebase

Rebase

Rebase