[PATCH] D76802: [InstrProfiling] Use !associated metadata for counters, data and values

Petr Hosek via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 10 19:57:35 PDT 2020


phosek added a comment.

I looked into these issue:

- http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/27806 failure was addressed by rG69c5ff4668cd4d1bfb6b45d71e15c12e3a23ae05 <https://reviews.llvm.org/rG69c5ff4668cd4d1bfb6b45d71e15c12e3a23ae05>
- https://ci.chromium.org/p/chromium/builders/try/linux_upload_clang/966 is unrelated and seems to be related to the use of BFD ld as the linker, I tried various experiments and it seems like BFD ld's handling of `SHF_LINK_ORDER` is broken, gold and lld handle this fine. Even if I can fix it, it's going to take years before that change gets to all the bots. I don't know how to address this other than requiring lld or gold for profile tests. Would that be reasonable?
- http://lab.llvm.org:8011/builders/clang-ppc64le-rhel/builds/4263 I cannot reproduce this locally, but what I think is happening is that your bot doesn't build lld, but this test requires lld (because we need working `SHF_LINK_ORDER` support) so when we pass `-fuse-ld=lld`, it uses the system lld which is likely outdated since the error we're seeing is coming from the bitcode reader. I think that we should either remove https://github.com/llvm/llvm-project/blob/master/compiler-rt/CMakeLists.txt#L539 or introduce a new lit stanza that means "lld is not only available, but was built as part of this build and is up-to-date".


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76802/new/

https://reviews.llvm.org/D76802





More information about the llvm-commits mailing list