In D104247#2831159, @spatel wrote:

LGTM.
Since we are opting for a definition of reassoc that is not a superset of the other flags, it might be worth seeing if transforms related to arcp and afn are similarly affected.

The default Altivec ABI was implemented

Address comments.

Address comments -- updated testcases.

In D104247#2828581, @pengfei wrote:

In D104247#2827116, @jsji wrote:

In D104247#2827089, @spatel wrote:

In code that I've looked at (mostly C compiled with -ffast-math), we always have contract when we have reassoc, so I don't see much practical difference.
Can you explain more how we could benefit from this change - in the example in the description, we would have 4 instructions rather than 3 if we use FMA - is that better?

Yes, you are right, the performance of having FMA should be better. However, we have quite some scenarios that users care about precision more than performance, they want to precise control of when FMA can be generated. So The major motivation of this is to ensure that we respect the IR semantics. For users that care about performance, we still can get them through default global option or emitting respect flag in IR.

AFAIU, the use of FMA doesn't decline the precision (but may improve a bit, which is also unexpected in some circumstance).

In D104247#2827089, @spatel wrote:

In code that I've looked at (mostly C compiled with -ffast-math), we always have contract when we have reassoc, so I don't see much practical difference.
Can you explain more how we could benefit from this change - in the example in the description, we would have 4 instructions rather than 3 if we use FMA - is that better?

I would prefer we implementing it using AtomicExpand , not using AtomicExpansionKind::LLSC , but with AtomicExpansionKind::MaskedIntrinsic.

Rebase to pick up Dave's D104255.

Address review comments.

Address review comments.

Done in https://reviews.llvm.org/D103707?

LGTM

LGTM with some nits.

Ping ...

LGTM. Thanks.

LGTM , with some comments on comments.

I don't think the YAML tools support generating 64-bit XCOFF objects yet, but we can add a precompiled object file as test input.

Looks mostly good to me, but I would prefer we split this into two fixes, one for the realign bp algorithm change, another for the other.

LGTM. Thanks for fixing.

This somehow was missed in my radar.. I will have a look .

Use isExactlyValue() for all floating-point types.

Fix isNullValue for ppc_fp128.

In D103634#2797005, @efriedma wrote:

Constant::isNullValue() is supposed to mean "is this value all zero bits"; various parts of the code use it that way. It shouldn't care whether the value is semantically equal to zero. Anything doing floating-point arithmetic should be using the appropriate ConstantFP/APFloat methods.

In D103634#2796960, @efriedma wrote:

If Constant::isNullValue() isn't returning the right result, please fix it directly. Getting it wrong could have other unexpected consequences.

Ping...

Looks like this is better than D103445, I would recommend go with this unless there is other comments. Thanks!

In D99901#2787034, @ted wrote:

Why would we not want to support this on other targets, like Arm? Fixes for AIX shouldn't impact other things.

Add option control to enable this feature.

I respectfully disagree with the requirement of mandating the canary word position.

Address comments.

Handle Internalize.

Address comments.

Address comments.

Update type of N to size_t.

Update update_llc_test tests as well.

Address comments.

Update .string handling.

Address comments.

In D102724#2769756, @jasonliu wrote:

Good idea, fyi, this is the patch: https://reviews.llvm.org/D83252

because AIX now has an alias implementation.