Updated the name of the option to vector-compare compat.
Added clang test lines to the test cases.
Added deprecation warnings to the current default behaviour of vector bool and
vector pixel.

In D103615#2799498, @bmahjour wrote:

As far as I can see, there is no good reason for the special treatment of vector bool/pixel going forward. Could we drop this special treatment, or at least change the default to use scalar results across the board (consistent with XL's behaviour and clang's current behaviour for most cases).

In D103700#2799532, @nemanjai wrote:

In D103700#2799340, @reames wrote:

In D103700#2799338, @nemanjai wrote:

We will be happy to test this on both our LE and BE systems. @stefanp do you have time to test this out or should I do it?

Seems like overkill for this one given the change is trivial and the test is target independent.

I'd save that for when I go to reapply the original patch that exposed this.

Oh, sorry. I meant to say that we'd test with this patch and the reverted one applied together.

@mkazantsev
I have reverted these changes (and subsequent related NFC patches) with the following patches:

commit 0159652058ca555b05db6a209fe9cf660c3bf8e6 (HEAD -> main, origin/main, origin/HEAD)
Author: Stefan Pintilie <stefanp@ca.ibm.com>
Date:   Fri May 28 11:35:25 2021 -0500

@mkazantsev
This change is breaking a couple of Power PC buildbots.
https://lab.llvm.org/buildbot/#/builders/105
https://lab.llvm.org/buildbot/#/builders/100
Since the bots have been broken for more than 24 hours I ask that you please revert the change and then recommit once the issues have been addressed.
If you have questions about reproducing the issue or need help with it please let me know.

Updated author to Quinn.

Rebased revision to top of trunk.

The fix has been committed.
You may now try to recommit this patch.

Added code comment.

It seems that this patch has exposed an issue in the PowerPC backend where the partword atomics were not actually guaranteed to be zero extended.
I've added a patch:
https://reviews.llvm.org/D102819
to fix the issue.

Added missing let isAllocatable = 0.

In D101342#2754174, @jrtc27 wrote:

In D101342#2754160, @stefanp wrote:

Hi @jrtc27

I apologize but we have not been able to get to the bottom of this quickly. As a result we have pulled the change with:

commit 8d37411e48202b490c62ee3548df4b90f5974e12 (HEAD -> main, origin/main, origin/HEAD)
Author: Stefan Pintilie <stefanp@ca.ibm.com>
Date:   Wed May 12 09:42:09 2021 -0500

    Revert "[SelectionDAG][Mips][PowerPC][RISCV][WebAssembly] Teach computeKnownBits/ComputeNumSignBits about atomics"
    
    This reverts commit 6c80361b8474535852afb2f7201370fb5f410091.
    Breaks PowerPC Big Endian buildbots.

I will keep you up to date as we have more information.
I have reopened this review.

I have access to big-endian PowerPC hardware. Is the reproducer as simple as running the compiler-rt test suite?

I apologize but we have not been able to get to the bottom of this quickly. As a result we have pulled the change with:

commit 8d37411e48202b490c62ee3548df4b90f5974e12 (HEAD -> main, origin/main, origin/HEAD)
Author: Stefan Pintilie <stefanp@ca.ibm.com>
Date:   Wed May 12 09:42:09 2021 -0500

Rebased patch and fixed typo in debug statement.

@jrtc27
It looks like this patch has broken one of out Big Endian PowerPC buildbots:
https://lab.llvm.org/buildbot/#/builders/93/builds/3021

Rebased to top of trunk.

Cleanup of test case.

In D101657#2735219, @efriedma wrote:

You probably also want the following testcase:

define void @UseLR() {
  tail call void asm sideeffect "", "{lr}"(i32 1)
  ret void
}

Cleanup the source code according to clang format.

LGTM

The point of the nt_flags= is to not overload the machine. We have noticed in the past that if we let the tests run all at the same time without a thread limit we sometimes get intermittent failing tests.
I think this is an option we should try to keep.

Was able to reproduce the issue that caused the left shift of -1.
Fixed the patch by replacing the shift with a multiply.
Also realized that the type should have been signed and not unsigned.

Thank you for the explanation!
LGTM.

Reopening review to investigate the issue.

Updated comment.

Updated test case to include -O0.

Removed extra whitespace.

Updated to always add the header to the got on PPC64.

I'll need to go over this again to refresh my memory. As a quick recap though:

• On PPC, if we create a .got, then the first entry must be the tocbase.
• If .TOC. is not defined by one of the input objects, then we do not increment the number of .got entries here
• If we synthetically define .TOC. in the linker, then we end up with a .got section in some cases where we would otherwise not need one.

Rebased the patch to the latest top of trunk and added the test case.

Looking at the test case changes there seem to be a few places where we are not generating expected code.
I've added comments to some of those places.

Ping.
I would like to restart the discussion on this patch.
I understand that the design of this fix is not ideal however I'm not sure of a better solution to this.
Adding the GOT to all linked binaries seems like too much. However, using hasGotOffRel isn't going to cover all of the test cases as it will not be set in all of the cases. The code needs to add a first symbol to the GOT in all cases where we use a GOT but we don't want to add a GOT if nothing else goes into it.