Rebased on trunk.

Thanks Jinsong, LGTM.

Thanks Jinsong, left a couple really minor comments. Will rebase the xxspltd fix on this patch now.

clang -target powerpc64le-unknown-linux-gnu  -c -o a.o  modern-as.s
 error: instruction use requires an option to be enabled
            mfudscr 2

IIUC this patch is breaking compatibility with gas due to the AIX assembler not supporting the mnemonic. Similarly for my xxspltd patch, we wouldn't be able to encode the mnemonic without passing extra options on Linux. Thats why I took the approach I did in D94419. I am happy to change direction, but in my opinion we should only be disabling the mnemonics on AIX.

In D94419#2491599, @jsji wrote:

I have added a Predicates in https://reviews.llvm.org/D94458 for a similar mne, maybe you can rebase this to use that.

Thanks Jinsong, LGTM.

If there is no objections, I'll go ahead and commit later this week.

Fixed one too many hyphens in man page change.

• Removed leading space in option description
• Updated the manpage doc.

On FreeBSD, the main use of this will be on the new powerpc64le arch, where we need to build a 32-bit LE bootloader for use with pseries. (it is easier to retarget LLVM than make a cross-endian bootloader, as it would involve rewriting filesystem code etc.)

Excuse my ignorance, but what are there technical limitations preventing writing n 64-bit LE boot loader and avoid having a 32-bit LE target all-together?

• Added -mattr=+altivec to vector pop count test to keep pwr5 testing
• Added a test to show enabling altivec through function attribute.

In D92324#2422992, @hubert.reinterpretcast wrote:

The altivec feature was an optional part of the 2.03 (pwr4) and 2.04 (pwr5) ISAs, and it was not implemented by any IBM CPUs until Power6.

The Power Processing Element in various IBM CPUs (including the Cell Broadband Engine) incorporate VMX. With this change, which of the CPU options should a user targeting a PPE use?

Sorry Zarko, I must have deleted my comment before posting last night I've added it back now.

1 comment, but otherwise LGTM.

LGTM.

A couple of really minor comments, but otherwise LGTM.

LGTM.

Thanks for the updates. LGTM.

• Add testing for warn-backrefs interaction.
• Spelling fixes
• Fix comments to use ## instead of # in lit test.

• Added a detailed comment trying to capture some of the linked discussion and distill why we want the more complicated lookup behaviour (at least by default).
• Added an option -fortran-common to toggle the new behaviour on/off.

In D86142#2360178, @psmith wrote:

I think that if this behaviour is to be put under an option, it is on by default. This will permit users to use both GNU ld and lld with the same command line.

• Add comments about why we have the special lookup behaviour for common in archives..
• Use NonCommon as opposed to UnCommon
• switch second if to be an else if instead.

• Added comment in the test describing why the behaviour change is needed.
• Converted a dyn_cast to a cast.
• Fixed paramater name to use lowercase.
• Fixed .size directives in the test to refer to the correct object.

Sorry, missed a comment.

Thanks for splitting this out XiangLing.

Commited in https://reviews.llvm.org/rGdfb717da1f794c235b81a985a57dc238c82318e6

More test coverage for this patch:

LGTM also.

Rebased.

We are in a poor position since this depends on D75059 which I never commit-ed since as I realized it was not really NFC because we were wrongly inserting VR_SAVE code for AIX. This had the effect of emitting a fatal error if we used vector arguments, return values and I believe if we selected any vector instructions. I never went back and updated it because there was always something higher priority to work on. I have a non-NFC update I haven't posted which relies on the calling convention lowering to emit an error when passing vector arguments, and I add an error when returning vector arguments. I will post that shortly.

• Add static on helper functions.
• Use ## for comments in lit test.
• Remove redundant parens
• Ignore locals when looking for overriding symbol def.

2 minor comments but otherwise LGTM.

In D87046#2288155, @ZarkoCA wrote:

In D87046#2285772, @sfertile wrote:

Does PPCMIPeephole::combineSEXTAndSHL have a similar problem that needs to be addressed?

I thought so, but it looks like that function is only called when PPCMIPeephole::simplifyCode sees an RLDICR Opcode which is a 64Bit only instruction. So it looks like we avoid this problem there.

Address review comments, switched test to use split-file instead of other inputs and macros, and simplified the test as much as possible.

Does PPCMIPeephole::combineSEXTAndSHL have a similar problem that needs to be addressed?

Extended the patch so that lazy object files are handled the same as archives, and bitcode files are handled same as native objects, both in archives and as lazy object files.

One minor nit, but otherwise LGTM.

Previous patch was not really NFC, since we were inserting VRSAVE pseudos on AIX, then emiting a fatal error in frame lowering. This was because we missed changing the condition gating the vrsave insertion to include the AIX abi.

One minor nit, but otherwise LGTM. If Nemanja would still like the comment he suggested make sure to address that before committing.

I've spent some time reading through the linked thread. Thanks. There is a lot to reply to so I hope I don't miss anything.

• Removed now unused local variable.
• Removed -framepointer=all option in lit test.
• Fixed formatting of runsteps in new lit test.

In D85994#2223415, @stefanp wrote:

I am unable to use the assembly files. The problem is that __tls_get_addr is a special name for the PPC backend and we cannot generate an object file from incorrect assembly. For example:

$ cat GeneralDynamic.s
	.text
GeneralDynamic:                         # @GeneralDynamic
	addis 3, 2, x@got@tlsgd@ha
	addi 3, 3, x@got@tlsgd@l
	bl __tls_get_addr()
	blr

Produces:

$ llvm-mc GeneralDynamic.s --filetype=obj -o /dev/null
GeneralDynamic.s:5:20: error: unknown token in expression
        bl __tls_get_addr()
                          ^
GeneralDynamic.s:5:20: error: invalid TLS call expression
        bl __tls_get_addr()
                          ^

LGTM.

In D84360#2215944, @nemanjai wrote:

But that's what check_LD_STD_W_PADDI does. Do you mean that I should add checks for the actual values?