LGTM with minor nit.

Could we add some rationale to the patch summary about why we would want to deliberately emitting an error for AIX?

Hi Fangrui(@MaskRay), are you okay with this patch to land as is?

In D88737#2321921, @MaskRay wrote:

A less intrusive approach is to not touch the existing InitTargetOptionsFromCodeGenFlags without parameters. You can add an initTargetOptionsFromCodeGenFlags with const Tripe & as its parameter.

Change lld's forwarder function's signature to match LLVM style.

This patch could be abandoned if D88737 gets acceptance.

An update follows up with the idea in D88748.

Not sure if there is a better way to do this. But I have to admit this approach along with D88493 is a bit fragile.
If plug-in writer forgets to set HasExplicitDataSections to true, then the final result that TargetMachine give for getDataSections() could be false on most platform even when they deliberately set DataSections to true.
We have other targets in LLVM that have -fdata-sections by default as well. And they do it differently as well, which makes this a bit more complicate to be consistent.
For example, cloudABI would pass -fdata-sections through the Clang Driver by default. But that approach means if some user just invoke llc directly, they could get the wrong default on llc for that platform.
Wasm would just overwrite the DataSections option to true in their TargetMachine. But that means you could not set it to false even if you want to.
I've thought about making the DataSections option in TargetOptions an enum instead of boolean value, where you could have Default, On and Off to represent what we actually want for the options. That's not a trivial change, as a lot of consumers for TargetOptions are relying it to be a boolean.
If you think it's a better way to solve this problem and I should explore, let me know.

In D88493#2304457, @hubert.reinterpretcast wrote:

@jasonliu: There's a lot of test adjustments to explicitly use the non-default, but I am not sure there is testing here to validate that the llc default when producing XCOFF assembly/object output is with unique data sections.

Address comments.

Rebase and addresses comments.

LGTM.

LGTM.

I think it would help the review if we could put the NFC portion(e.g. TypeSize -> StorageUnitSize) to a new patch, and give some rationale about the NFC change.

LGTM.

LGTM.

Added debug

In D86879#2274076, @nemanjai wrote:

In D86879#2274025, @hubert.reinterpretcast wrote:

We believe that the test is necessarily large. Has the associated bot encountered similar issues before? What was the recommended fix to retain the test in more appropriate environments?

Perhaps the test case should be restricted to some key platforms where cross-compilation to AIX is relevant? Perhaps Linux (PPC is already required).

I think this could achieve the same effect by writing out a loop, and running the unroller to generate the target IR. Alternatively, I think you can craft the same situations without giant IR. For example with the spill-O1 case, you should be able to use some large stack objects and then trigger spilling with a shorter sequence. I assume all of the objects leading up to the spill don't need to be spills to hit the out of range behavior

In rG9868ea764f31b0fd4ec250867807aa0ad7958abf#946697, @arsenm wrote:

I think it's inappropriate to have test IR be generated like this. This test is also incredibly slow. It takes a full 30 seconds for me with a debug build

Address comments from Digger.

Address comments.

Address review comments.

In D85774#2217649, @jhenderson wrote:

It seems to me like this should be using inheritance here. You have a base class that has the common members, and provides pure virtual declarations of the various getters, with the sub-classes defining them to do the right thing. Yes, it would introduce a number of getters, but I feel like it would make everything a bit cleaner from a usability standpoint. In most cases, you then don't need any is64Bit queries, because the getters hide that from you.

Addresses comments.
Add in test case to test errors.
Use view/reference class to encapsulate 32-bit and 64-bit differences instead.

Address comments.

Report fatal error when we know the initial 64kb TOC region is not enough to contain all the TOC entries.

LGTM.