Thanks for the review! :)

@phosek Pinging this patch, our builders which run check-all and expect compiler-rt, enabled as a runtime with -DLLVM_ENABLE_RUNTIMES=compiler-rt, to be covered in testing are not doing this and are still being affected by this changeset.
clang-ppc64le-rhel and clang-ppc64-aix are not currently testing compiler-rt because of this change.
clang-ppc64le-linux-test-suite enables compiler-rt as a project with -DLLVM_ENABLE_PROJECTS=compiler-rt and test it under check-all as expected.
Before this, both bots would test compiler-rt under check-all. Could you please take a look at this?

Thank you!

This update removes the edits made to the TestSuiteBuilder, as they are not
critical to the PR, we will not be moving away from the UnifiedTreeBuilder
as a base for the TestSuiteBuilder.

Planning to move away from the UnifiedTreeBuilder for our TestSuiteBuilder

In D125499#3541689, @tstellar wrote:

I'm curious what is your system configuration where this patch actually allows for detection of devtoolset? I noticed that if clang and gcc are both installed to /usr/, then driver will pick the gcc in /usr/ over the one in /opt/rh/.../

In D123060#3447349, @gkistanova wrote:

Depending on the build requests queues any combination of 2 concurrent builds is possible. Yes, it is possible to have 2 ppc64le-flang-rhel-clang builds running and ppc64le-mlir-rhel-clang builds waiting.

Creating separate workers for the flang and mlir ppc64le builders to remove any
dependency on build request order between the two bots as was pointed out in a
previous review.

In D123060#3428541, @gkistanova wrote:

Hello Kamau,

ppc64le-flang-rhel-clang seems using a lot of resources. It takes up to 15 minutes to build when it uses the computer exclusively.

What is the expected build time when 2 ppc64le-flang-rhel-clang builds will be running simultaneously on the same computer?

I'm sorry I took so long to notify you but I need to bring these bots back to green as soon as possible, they have been broken too long.

This option appears to incorrectly warn warning that unsigned NumEntries = getNumEntries(); is "set but not used" in llvm/include/llvm/ADT/DenseMap.h:129 and so it is breaking the ppc64le-lld-multistage-test bot.
This could be because the only use is in an assert which is in a corner case maybe?

In D121654#3391141, @jrtc27 wrote:

In D121654#3391091, @kamaub wrote:

In D121654#3390916, @jrtc27 wrote:

Does:

diff --git a/llvm/lib/Target/RISCV/RISCVISelLowering.cpp b/llvm/lib/Target/RISCV/RISCVISelLowering.cpp
index f52965dab759..299c68da7c2f 100644
--- a/llvm/lib/Target/RISCV/RISCVISelLowering.cpp
+++ b/llvm/lib/Target/RISCV/RISCVISelLowering.cpp
@@ -3769,6 +3769,15 @@ SDValue RISCVTargetLowering::getAddr(NodeTy *N, SelectionDAG &DAG,
   }
 }
 
+template SDValue RISCVTargetLowering::getAddr<GlobalAddressSDNode>(
+    GlobalAddressSDNode *N, SelectionDAG &DAG, bool IsLocal) const;
+template SDValue RISCVTargetLowering::getAddr<BlockAddressSDNode>(
+    BlockAddressSDNode *N, SelectionDAG &DAG, bool IsLocal) const;
+template SDValue RISCVTargetLowering::getAddr<ConstantPoolSDNode>(
+    ConstantPoolSDNode *N, SelectionDAG &DAG, bool IsLocal) const;
+template SDValue RISCVTargetLowering::getAddr<JumpTableSDNode>(
+    JumpTableSDNode *N, SelectionDAG &DAG, bool IsLocal) const;
+
 SDValue RISCVTargetLowering::lowerGlobalAddress(SDValue Op,
                                                 SelectionDAG &DAG) const {
   SDLoc DL(Op);

fix the error for you?

I'd be happy to review and approve a patch with this change but I think the fastest resolution to getting the bot back to green would be to revert and then recommit with this change added. The bot has been broken for over 24 hours so we would like to get it back online as soon as possible, thank you for your quick response. :)

I've just committed the fix as 63ea7797dd5bb77cc7b2904e20a5b779d30d4f2d; strange how this exposes it but it's been lurking ready to break since 41454ab25645 / D114950.

The test cases added with this commit failed on clang-ppc64be-linux-lnt # 13809 could you please revert this change, and recommit with the test case corrected? thank you.

In D121654#3390916, @jrtc27 wrote:

Does:

diff --git a/llvm/lib/Target/RISCV/RISCVISelLowering.cpp b/llvm/lib/Target/RISCV/RISCVISelLowering.cpp
index f52965dab759..299c68da7c2f 100644
--- a/llvm/lib/Target/RISCV/RISCVISelLowering.cpp
+++ b/llvm/lib/Target/RISCV/RISCVISelLowering.cpp
@@ -3769,6 +3769,15 @@ SDValue RISCVTargetLowering::getAddr(NodeTy *N, SelectionDAG &DAG,
   }
 }
 
+template SDValue RISCVTargetLowering::getAddr<GlobalAddressSDNode>(
+    GlobalAddressSDNode *N, SelectionDAG &DAG, bool IsLocal) const;
+template SDValue RISCVTargetLowering::getAddr<BlockAddressSDNode>(
+    BlockAddressSDNode *N, SelectionDAG &DAG, bool IsLocal) const;
+template SDValue RISCVTargetLowering::getAddr<ConstantPoolSDNode>(
+    ConstantPoolSDNode *N, SelectionDAG &DAG, bool IsLocal) const;
+template SDValue RISCVTargetLowering::getAddr<JumpTableSDNode>(
+    JumpTableSDNode *N, SelectionDAG &DAG, bool IsLocal) const;
+
 SDValue RISCVTargetLowering::lowerGlobalAddress(SDValue Op,
                                                 SelectionDAG &DAG) const {
   SDLoc DL(Op);

fix the error for you?

In D121654#3390888, @jrtc27 wrote:

In D121654#3390865, @kamaub wrote:

I have confirmed that this patch cause a miscompile on our sanitizer-ppc64be-linux #4255 bot, please investigate and fix this as soon as possible, thank you.

The log says:

../../../../lib/libLLVMRISCVCodeGen.a(RISCVISelDAGToDAG.cpp.o): In function `selectImm(llvm::SelectionDAG*, llvm::SDLoc const&, llvm::MVT, long, llvm::RISCVSubtarget const&)':
RISCVISelDAGToDAG.cpp:(.text._ZL9selectImmPN4llvm12SelectionDAGERKNS_5SDLocENS_3MVTElRKNS_14RISCVSubtargetE+0x3d8): undefined reference to `llvm::SDValue llvm::RISCVTargetLowering::getAddr<llvm::ConstantPoolSDNode>(llvm::ConstantPoolSDNode*, llvm::SelectionDAG&, bool) const'
collect2: error: ld returned 1 exit status

Other buildbots are totally fine, as are my local builds. I really do not see how on earth _this_ change can cause the function I'm editing to no longer exist, unless the host toolchain is just broken.

In D121654#3390916, @jrtc27 wrote:

Does:

diff --git a/llvm/lib/Target/RISCV/RISCVISelLowering.cpp b/llvm/lib/Target/RISCV/RISCVISelLowering.cpp
index f52965dab759..299c68da7c2f 100644
--- a/llvm/lib/Target/RISCV/RISCVISelLowering.cpp
+++ b/llvm/lib/Target/RISCV/RISCVISelLowering.cpp
@@ -3769,6 +3769,15 @@ SDValue RISCVTargetLowering::getAddr(NodeTy *N, SelectionDAG &DAG,
   }
 }
 
+template SDValue RISCVTargetLowering::getAddr<GlobalAddressSDNode>(
+    GlobalAddressSDNode *N, SelectionDAG &DAG, bool IsLocal) const;
+template SDValue RISCVTargetLowering::getAddr<BlockAddressSDNode>(
+    BlockAddressSDNode *N, SelectionDAG &DAG, bool IsLocal) const;
+template SDValue RISCVTargetLowering::getAddr<ConstantPoolSDNode>(
+    ConstantPoolSDNode *N, SelectionDAG &DAG, bool IsLocal) const;
+template SDValue RISCVTargetLowering::getAddr<JumpTableSDNode>(
+    JumpTableSDNode *N, SelectionDAG &DAG, bool IsLocal) const;
+
 SDValue RISCVTargetLowering::lowerGlobalAddress(SDValue Op,
                                                 SelectionDAG &DAG) const {
   SDLoc DL(Op);

fix the error for you?

I have confirmed that this patch cause a miscompile on our sanitizer-ppc64be-linux #4255 bot, please investigate and fix this as soon as possible, thank you.

This change broke the clang-ppc64le-rhel #15899 bot. It actually pass this and every other bot green
but the next build after sanitizer test cases on clang-ppc64le-rhel #15900 for continuous builds fails,
that is, some clean builds pass but mostly continuous builds fail.

Test case clang/test/CodeGen/ppc-mm-malloc.c fails on powerpc BE buildbots with this changeset
https://lab.llvm.org/buildbot/#/builders/93/builds/6031
https://lab.llvm.org/buildbot/#/builders/100/builds/10836
https://lab.llvm.org/buildbot/#/builders/52/builds/12719

Adding shift variable test case to builtins-ppc-xlcompat-rotate.c as per
review comment request.

Addressing review request to remove unnecessary testing line.

Yeah this LGTM as well, accidentally commented without accepting a moment before.

Updated an existing test for the backend with pwr8 and pwr9 be/le targets during commit

Moving test case to correct file before commiting as request in review comment.

Rebasing patch to get past intermittent test-suite failure

Rebasing this patch and addressing review comments

This patch seems almost ready to land to me, I'm just a bit concerned about the testing coverage,
is the little endian testing case suppose to target pwr7 as the big endian test does? The default
FileCheck line seems redundant to me, did I misunderstand?

The condition for failing semantic chequing on mma builtins was incorrect,
updating this patch to correctly check the semantics and associated testing.

This LGTM, small nit on the comment, but that can be fixed on commit

This LGTM

This LGTM

Hello, sorry but can you please revert this commit and recommit it when you have a fix or work around that doesn't break our bots:
It breaks http://lab.llvm.org:8011/builders/ppc64le-lld-multistage-test/builds/11228 which builds with -Werror
Please also note that it introduced 103 warnings in clang-ppc64le-linux-multistage/builds/13042

Rebasing and updating patch to use TLS enablement option.

Rebasing patch on D85448 and editing test cases to use enablement option.

Replacing assert() with report_fatal_error()

Rebasing on most recent D81947 and addressing review comments:

• rebasing on the updated version of D81947
• updating test cases according to review comments
• updating comments in code
• updating llvm-readobj run lines to follow new interface

Rebasing and addressing review comments:

• rebased on the updated version of D82315
• updated test cases according to reviews
• updated llvm-readobj run lines in test cases to reflect interface change