Fixed bug with missing offset in object file.

Addressed review comments.
Added new test cases to cover a number of different call situations.

Addressed review comments for the code.
Added a test case that will check both the assembly and do an llvm-objdump of the object file.

Thank you for fixing this Amy.
LGTM.

It is correct that the code did not need to be moved. I've moved it back.

Talked this over with the team and we have decided on a way to rename that class. See the comment.

Accidentally added unnecessary code when I did a rebase. Removed that now.

Removed inaccurate debug statement.

Fixed comments in the code as requested by reviewers.

Disabled Tail Calls for when using PC Relative. That will be fixed in a later patch.

Address Review Comments

Missed a tconstpool that should have been a pcreladdr.

Removed the PCRelative guard that was incorrectly placed in PPCTargetLowering::SelectAddressRegRegOnly.
Removed the isPrefix class from the td file as it was not required.
Added more comments to the PPCInstrPrefix.td.

Cleaned up patch and removed the NFC part.
Also added a couple of new patterns to the td file and added a new PPCISD node MAT_PCREL_ADDR. The only purpose of this new node is to materialize PC Relative addresses.

Fixup for tests test/MC/PowerPC/ppc64-localentry-error1.s and test/MC/PowerPC/ppc64-localentry-error2.s.

Created a new review for only the NFC Hexagon changes here: https://reviews.llvm.org/D74788
Next, I will rework this patch.

Addressed review comments as well as the issue with MO_ExternalSymbol. I've added a test case for the situation where MO_ExternalSymbol is required.

Mostly nits from me.

Couple of nits but overall LGTM.

Address review comments.

Address a number of review comments.

Address review comments.

Addressed review comments.

Addressed review comment by hard coding the prefix for MLS_DForm2_r0.

Address review comments.

Added full context.

Added full context.

Added full context.

Other than the test case which still needs to be updated I think that this patch looks good to me.

It took me a while to determine that this was in fact NFC.
Removing the whole:

if (HasAnyUndefs || ISD::isBuildVectorAllOnes(BVN)) {
...
}

threw me off.
I'm convinced now so I'll approve it.
The minor nit that I have can be done on commit.

Please add a test case for this.
Maybe an test were we have an SPE load of f64 with a 8 bit offset and one where the offset is larger or perhaps not aligned. Anyway, that's just a suggestion. You probably have a better idea of what you would like to test for this.

I think that for f64 on SPE the GprIndex you are computing it going to be ignored. (See my comment...)

I only saw a minor nit with this patch overall.

LGTM

LGTM

I think this patch is fine now.
I only have one minor comment.

Mostly minor comments and a couple of questions.

Please make sure that your test does not put restrictions on the allocation of output registers. See my comments.
Otherwise I think this looks fine.

LGTM.
Sorry for taking so long to get to this.

Thank you for fixing this.
LGTM.

I took this patch and applied it to master today and I noticed that one of the LIT tests fails.
The test is:

test-suite/MultiSource/Benchmarks/tramp3d-v4/

It segfaults with this patch and runs fine with out it.
I took a quick look at it and it seems that in this basic block:

; predecessors: %bb.11, %bb.12, %bb.13
  successors: %bb.21(0x80000000); %bb.21(100.00%)
  liveins: $r6, $r7, $r9, $x4, $x5, $x10, $x12, $x30, $r8
  renamable $x3 = ADDI8 $x1, 32
  STW killed renamable $r8, 32, $x1 :: (store 4 into %ir.arrayidx.i.i.i.i.i.i.i.i424, align 8), (store 4 into %ir.129, align 8)
  STW killed renamable $r6, 36, $x1 :: (store 4 into %ir.132)
  STW killed renamable $r7, 44, $x1 :: (store 4 into %ir.134)
  STW killed renamable $r9, 52, $x1 :: (store 4 into %ir.136)
  renamable $x3 = ADD8 killed renamable $x3, killed renamable $x5
  renamable $x5 = nsw ADD8 killed renamable $x10, killed renamable $x12
  renamable $r3 = LWZ 4, killed renamable $x3 :: (load 4 from %ir.137)
  renamable $x5 = nsw SUBF8 renamable $x4, killed renamable $x5
  STW8 killed renamable $x4, 24, renamable $x30 :: (store 4 into %ir.141)
  renamable $r3 = ADD4 killed renamable $r3, killed renamable $r5, implicit $x5
  B %bb.21

We replace

renamable $x3 = ADDI8 $x1, 32
renamable $x3 = ADD8 killed renamable $x3, killed renamable $x5
renamable $r3 = LWZ 4, killed renamable $x3 :: (load 4 from %ir.137)

with:

renamable $x3 = ADDI8 $x1, 36
renamable $r3 = LWZX killed $x5, killed $x3 :: (load 4 from %ir.137)

However, it looks like x5 is redefined before the load so using it in the LWZX is not safe because it is not the same x5 as before.

Thank you Galina!
Committed at r371652.

Thank you Galina!
Committed at r372342.

@gkistanova
Thank you for reviewing this Galina.
I don't have commit access to zorg. Can you commit this for me?

I do have a couple additional comments.