Is there any precedent for options that start with -maix or -m<OS> for any other OS?

Address comments.

Gentle ping.

In D127554#3606867, @thakis wrote:

Looks like this breaks tests on non-linux: http://45.33.8.238/macm1/37997/step_11.txt , http://45.33.8.238/win/60800/step_11.txt

Please take a look and revert for now if it takes a while to fix.

Rebased.

LGTM.

LGTM as nemanja has detailed explanation for my concern.

This fix looks making offset handling more complex. We can make it easier by add LQX_PSEUDO and STQX_PSEUDO to ImmToIdxMap.

ImmToIdxMap[PPC::LQ]  = PPC::LQX_PSEUDO;
ImmToIdxMap[PPC::STQ] = PPC::STQX_PSEUDO;

And expand PPC::LQX_PSEUDO and PPC::STQX_PSEUDO post RA(They are expanded in PPCTargetLowering::EmitInstrWithCustomInserter right now). Thus we make LQ/STQ fits in how we are handling frame index now, no more code is needed to handling the offset for LQ/STQ(When LQ/STQ are selected by ISEL, alignment is guaranteed to be 16 bytes since they are for atomic operations).

Avoid using undef in tests.

In D127554#3578625, @vchuravy wrote:

This looks great. Is this safe to backport to LLVM13 or LLVM14?

Address comments.

Added original reduced case from @nemanjai .

Rebased to where float tests are added.

That would be expanded in PPCInstrInfo::expandPostRAPseudo()

I think the root cause here is lq/stq is leaking x-form. There are LQX_PSEUDO and STQX_PSEUDO defined to assist accessing big offset inside the stack, but there are expanded pre-RA. I think we should expand them in PPCAtomicExpandPass and make lq/stq's x-form mapping to LQX_PSEUDO/STQX_PSEUDO.

I'm not sure if it's appropriate to use clang and compiler-rt in different versions. Added more reviewers for discussion.

Address comments.

The problem (my concern) here is some architecture may not be ready to use isCopyInstr to identify what a COPY is.

Could you please describe briefly what copy-like instructions MCP is missing in the summary?

Gentle ping.

The troubled instruction was introduced for both P7 and A2 as below link shows:
https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20130325/169706.html

Ping.

Gentle ping.

Updated affected tests.

ping.

The issue is fixed by https://reviews.llvm.org/D122868. We don't need to lower cfence when emitting __atomic* libcalls.

Rebased.

LGTM with nit.

Hi, this patch is breaking https://lab.llvm.org/buildbot/#/builders/37/builds/12263 https://lab.llvm.org/buildbot/#/builders/19/builds/10280, could you please take a look?

Address comments.

Address comments.

In D122377#3428533, @hubert.reinterpretcast wrote:

I am not sure that the choice of isOSBinFormatELF to (afaik) primarily scope this change from affecting AIX (where we know the library calls are not implemented to be lock-free yet) is better than alternative where the condition is for little-endian mode or specifically for not AIX.

What this patch intended to do is covered by https://reviews.llvm.org/D120230.

Make 16-byte atomic type aligned to 16-byte on PPC64.

Could you also add test of opt -passes='default<O3>' to ensure we don't optimize it out for the motivation case?

Thanks @efriedma for pointing out. Updated guard code. Removed -mllvm while adjusting backend to reflect ABI change.

Removed alter of -ppc-quadword-atomcis in backend to decouple from frontend.

@dim @pkubaj We are modifying layout of 16-byte atomic type on Linux to be consistent with GCC, I don't know if it also applies to freebsd as @MaskRay pointed out.
To be more specific, on Linux, for arch level supporting 16-byte lock free atomics, 16-byte atomic type should be properly aligned.

#include <stdatomic.h>

Please also add tests.

Most are covered by https://reviews.llvm.org/D122377 already.