This looks good to me, just some request that can be done pre-commit

Removing the "mayRaiseFPException" predicate as it does not apply to these instructions.

Addressing a review comment.

This LGTM, thank you.

Addressing review comments.

Addressing review comments.

Spelling mistake

Updating wording.

First review, I'll try to comeback again soon.

Thank you for this patch, just some review comments.

Hello, sorry for missing you ping and delaying the patch so long just for test case adjustments, thank you for addressing them.
Everything LGTM but lei and I had one request that can be made before you commit:

Sorry I should have requested changes before for this comment below, but I do want these test moved to codegen and expanded, please let me know if anything is unclear.

In D143467#4241667, @kamaub wrote:

Can you add a PowerPC codegen test case for __attribute__((target(? All of the updated test cases seem to only test -target-feature.
The only test case we have for __attribute((target( is a sema test ./clang/test/Sema/ppc-attr-target-inline.c.

Converting the deleted clang/test/Sema/ppc-mma-builtins.c and clang/test/Sema/ppc-paired-vector-builtins.c to a codegen test cases
like clang/test/CodeGen/PowerPC/builtins-ppc-htm.c using FileCheck seems like a nice solution since it would reintroduce the testing
for +paired-vector-memops,-mma situations, as well as a for __attribute__((target("no-mma")))

Can you add a PowerPC codegen test case for __attribute__((target(? All of the updated test cases seem to only test -target-feature.
The only test case we have for __attribute((target( is a sema test ./clang/test/Sema/ppc-attr-target-inline.c.

Request changes because of the bug in the isShuffleMaskInRange() conditions

We may also need an associated test case for the changed behaviour for using areCompatibleVectorTypes() instead of areSameVectorElemTypes().
The test coverage should display when warnings are emitted now that we account for vector bool, vector pixel and type qualifiers.

Some comments from the llvm-on-power team:

Thank you for the review, I have removed the necessary quotations.

Addressing review comments

ping

Addressing review comments

https://lab.llvm.org/buildbot/#/builders/230/builds/4037/steps/7/logs/stdio Here is a example log, I will try to get a backtrace for you.

Sorry, I didn’t see your message in time and I reverted. Please let me know if we can help by providing access to a machine where you can test any potential fixes so that you can re-commit.

Please hold off on commit anymore patches until the test breaks identified by my colleague in https://reviews.llvm.org/D134226#3858268 are resolved.
Several scudo test are intermittently failing on multiple powerpc bots https://lab.llvm.org/buildbot/#/builders?tags=%2Bppc
I am able to reproduce the failure on a ppc machines with a stress test:

 ~/llvm/mono/bot_reprod $ cat ~/stress-scudo.sh
RC=0
while [[ $RC == 0 ]]; do
  ninja check-runtimes >> stress-scudo.log
  RC=$?
done

which fails on the 1st, 2nd or 3rd loops (hence the flaky behaviour on the bots)
and I was able to confirm that by applying these reverts the flaky behaviour of ./ScudoUnitTest-powerpc64le-Test/163/220 and ./ScudoUnitTest-powerpc64le-Test/ScudoPrimaryTestMemoryGroup_TestConfig3/MemoryGroup disappear

~/llvm/mono/llvm-project $ git revert fd7c7ad4fe0138314b922ea0db1691d5a679cc75
[main 77190d04d010] Revert "[scudo] Fix implicitly narrow casting (NFC)"
 3 files changed, 5 insertions(+), 10 deletions(-)
~/llvm/mono/llvm-project $ git revert 9c26f51f5e178ac0fda98419e3a61d205d3b58b1
[main d982b881645e] Revert "[scudo] Support partial page releasing"
 4 files changed, 19 insertions(+), 91 deletions(-)
~/llvm/mono/llvm-project $ git revert cf9d7f55d3bec7640fa8b2f8ec1d9c1268233caa
[main 556f28478a6c] Revert "[scudo] Manage free blocks in BatchGroup."
 8 files changed, 67 insertions(+), 635 deletions(-)

The flaky tests still fail after reverting 9c26f51f5e178ac0fda98419e3a61d205d3b58b1 so cf9d7f55d3bec7640fa8b2f8ec1d9c1268233caa is likely the culprit but I will have to revert all three patches since they are dependent on each other in a chain i.e I must revert fd7c7ad4fe0138314b922ea0db1691d5a679cc75 in order to revert 9c26f51f5e178ac0fda98419e3a61d205d3b58b1 in order to revert cf9d7f55d3bec7640fa8b2f8ec1d9c1268233caa

Thank you for the review, I am testing these changes at the moment, will post the update afterwards.

This change causes a linking failure during the check-all testing of 'clang-tools-extra' on the clang-ppc64le-rhel #22596 and clang-ppc64le-linux-multistage #23864 build bots, please address this failure as soon as possible.

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?