Final nits

This kind of blindly applying clang-tidy -checks='-*,performance-for-range-copy' --fix changes is easy for the contributor but is time consuming for reviewers.
Anyway, I have applied appropriated fixes to places where const auto & is not the best.

Use std::size to avoid referencing vector size by integer literals

Are __asan_abi_register_elf_globals needed if non-Apple systems don't build lib/asan_abi?

Other than -Wframe-larger-than=656 and const uptr indicator = 0x0f0000000000ull; changes, others looks good to me.
I agree that this should be reviewed by @dvyukov :)

(The lld patch may take some time. I'll be out of town for about 10 days.)

The Clang Driver/CodeGen and compiler-rt changes look good to me. Of course please wait for an Android reviewer :)

LGTM

LGTM! Thanks for bearing with me about all the nits.

lld/docs/ld.lld.1 needs an update as well. The format is difficult to write... you can use man lld/docs/ld.lld.1 to check whether it looks right.

Thanks for the update.

Thanks for the update. Doing the following looks good to me.

bool CanHaveLeadingDot = true;
if (StripUnderscore)
  if (DecoratedStr[0].consume_front("_")) // simplified
    CanHaveLeadingDot = false;

In D152840#4650105, @MaskRay wrote:

Instead of having a --use-*, the best is probably to create a JJ<"call-graph-profile-sort=", ...> (values: hfsort,cdsort),
make the existing --call-graph-profile-sort an alias (FF<"call-graph-profile-sort", ...>, Alias<call_graph_profile_sort>, AliasArgs<"hfsort">),
then add a BB for --no-call-graph-profile-sort.

(I'll be out of town during 9-29 ~ 10-9)

.

Instead of having a --use-*, the best is probably to create a JJ<"call-graph-profile-sort=", ...> (values: hfsort,cdsort),
make the existing --call-graph-profile-sort an alias (FF<"call-graph-profile-sort", ...>, Alias<call_graph_profile_sort>, AliasArgs<"hfsort">),
then add a BB for --no-call-graph-profile-sort.

DataLayout needs a unittest in llvm/unittests/IR/DataLayoutTest.cpp

In rG05926a5a557878aa233ac8431b3acddf54422e58#1251905, @MaskRay wrote:

It's very late for me and I don't have much time to create a smaller reproduce. This patch caused an assertion failure in AArch64ISelLowering.cpp:4435

assert(N->getOpcode() == ISD::BUILD_VECTOR && "expected BUILD_VECTOR");

N is AssertZext

It's very late for me and I don't have much time to create a smaller reproduce. This patch caused an assertion failure in AArch64ISelLowering.cpp:4435

assert(N->getOpcode() == ISD::BUILD_VECTOR && "expected BUILD_VECTOR");

llvm::demangle is used by a lot of ELF tools to assume ELF style mangling where there is no extra prefix. I think many don't expect demangling ._Zxxxx symbols.
If XCOFF needs ., I think separate functions are needed. You can add a new utility function or extending demangle with an optional parameter about XCOFF.

Thank you for the stamp. I'll land this soon so that D152840 can rebase on top of it and we can have D152840 soon...

So this is truly a test of the ld.otherlinker feature pattern, not some special case driver feature. I guess we should leave the test alone.
Closing, we left the test alone, it still uses -fuse-ld=lld-link2. Perhaps in the future we should reconsider this, but that's how things stand now, and we aren't going to land this patch as is. + @MaskRay , who has thought about -fuse-ld= semantics.

I have also explained that SmallVector<*, 0> is preferred in lld/ELF code, so I have a vector => ArrayRef refactoring.
We should also get rid of buildCallGraph, which uses a number of output parameters, while the function can just be inlined into apply* (to be renamed).

In D152840#4649238, @spupyrev wrote:

D159526 performed the rename. If this patch is applied, applyCDSort in lld/ELF will need to be updated again. This is exactly the scenario I want to avoid.

Can you explain why renaming a function might be a problem and we may want to avoid this either in the linker or in the compiler?

I am not fully convinced that the newly proposed naming is preferred over the existing one. The new algorithm is called "cdsort" (which mimics the existing and commonly accepted name of "hfsort"), and it makes a sense to call the corresponding function "applyCDSort" as in "applyAlgorithmX". In contrast, "computeXXXlayout" might feel confusing, since the word "layout" often means a process.

In rGa18ee8b7c95c6dfa410c6acaaf8cffcfde1220b5#1251481, @vvereschaka wrote:

Hi @MaskRay

This test gets failed on llvm-clang-x86_64-expensive-checks-ubuntu builder
https://lab.llvm.org/buildbot/#/builders/104/builds/13527/steps/6/logs/FAIL__LLVM__pseudo-probe-emit_ll

In D152840#4648633, @spupyrev wrote:

In D152840#4648582, @MaskRay wrote:

In D152840#4648483, @spupyrev wrote:

In D152840#4648482, @MaskRay wrote:

Thanks for the update. I am mainly waiting for the renamed function (applyCDSort does not convey the meaning well), changes of nested std::pair and std::vector => SmallVector<*, 0>

I have an impression the changes are made in the follow-up D159526 (which I'd prefer to land after this one). Do I miss something?

You are right. You may rebase this patch on top of D159526 :)

I suggest to rebase D159526 on top of this one

Please, when landing a large patch, check whether clang can build the project. The original commit caused -Wswitch failure which I fixed in ca22d6e40508f6d24a9352835bda9c152e3eee1b.

In D155711#4648971, @MaskRay wrote:

In D155711#4648928, @MaskRay wrote:

Early heads-up we internally have identified a crash due to this change.

I will try giving a reproduce later, but am reverting this now.

musttail call must precede a ret with an optional bitcast

In D155711#4648928, @MaskRay wrote:

Early heads-up we internally have identified a crash due to this change.

Early heads-up we internally have identified a crash due to this change.