I only have a number of very minor comments. Overall I think this looks good.
I think you can fix the comments when you commit.

@gkistanova
Hi Galina,
We are having intermittent svn failures on our lnt build bot as a result of this http vs. https issue. (The bot: http://lab.llvm.org:8011/builders/clang-ppc64be-linux-lnt)
Would it be possible to take a look at this patch because we think that this will fix our bot.
Thank you!

Committed by this patch:

commit 0a4f7b2312b55e8f3144cbb9e658bc37cc4fc779
Author: Galina Kistanova <gkistanova@gmail.com>
Date:   Mon Feb 25 20:19:36 2019 +0000

LGTM.

You have convinced me that this will only affect AIX. I only have minor comments remaining.

I feel like this is supposed to be an AIX only patch.
However, there are some cases where you are making changes to PowerPC platforms that are not AIX. I don't know if those changes are safe.
I'm going to add two people to the review who may be interested in this and who work on 32 Bit PowerPC.

I'm not super familiar with the MC layer but overall this looks good to me.
I have a couple of minor comments.

I only have one comment here and I think it can be fixed when the patch is committed.
LGTM.

LGTM.
The one very minor comment I have I think can be addressed on commit.

I have a couple of nits. The main one being the test case for fma-mutate.ll.
I'm not sure if there is a way to use one const NR for just that one test.

Looks good to me.
Then only thing I noticed was that in the description in the LanguageExtensions.rst file you use plural to refer to the chache builtins. Of course, you only added one builtin but I know that in the future you plan to add more builtins of the same type so I wouldn't worry about that wording now.

The patch does what we want it to do in most cases (including the example that motivated it) but some boundary conditions need to be considered before it is safe in all cases.

@nemanjai
I will commit this for Victor.

Have a couple of minor nits about the test case but that is all.
LGTM.

LGTM

Minor nit that can be fixed when this patch is committed.
LGTM.

The reason why we don't clean up that extra store on no-PIC is because we run a couple of extra passes for PIC for PowerPC.
It is this code:

// FIXME: We probably don't need to run these for -fPIE.
if (getPPCTargetMachine().isPositionIndependent()) {
  // FIXME: LiveVariables should not be necessary here!
  // PPCTLSDynamicCallPass uses LiveIntervals which previously dependent on
  // LiveVariables. This (unnecessary) dependency has been removed now,
  // however a stage-2 clang build fails without LiveVariables computed here.
  addPass(&LiveVariablesID, false);
  addPass(createPPCTLSDynamicCallPass());
}

Those extra passes clean up the extra store.
If I remember correctly this is only really an issue at -O0. At higher opts other passes clean up stores like that.

@hfinkel @nemanjai
Hi,
Sorry for the late reply. It took me a little while to figure out that I had specified the wrong options for my test when trying to reproduce this....
Anyway, I've verified that what Nemanja said is indeed correct:
no-PIC

bl      100006b0 <00000017.plt_call.omp_control_tool@@VERSION>                                       
ld      r2,24(r1)                                                                                    
nop                                                                                                  
stw     r3,108(r31)
nop

PIC

bl      100006b0 <00000017.plt_call.omp_control_tool@@VERSION>
ld      r2,24(r1)
nop
nop

The store in the no-PIC version is just saving the return value from r3.

Ping.

Fixed according to review comments.

Committed revision 353994 with the test cases as NFC.
Will update the patch for the remaining comments soon...

Hi Hal,
I'm actually not going to do this in the end.... I'm just going to abandon this patch.
I realized that we did actually need this type too.

Hi Hal,
Thank you for the review.
I've looked around but the only place we use u1imm is where we only have 1 bit to use in the instruction anyway so we have no way to represent -1 anyway.

This patch was committed by Galina in r352652.

Gentle ping..

Looked through this and tried a couple of things but overall it looks good.
My only comments are a couple of minor nit items.

No longer working on this.

Closed.

Addressed comments from Jinsong.

@gkistanova
Hi Galina,
Thank you for approving this.
I'm sorry but I have to change it a little bit. I just realized that the previous changeset was setting -DLLVM_ENABLE_LLD on both stage1 and stage2 builds and that won't work. We just want that option on stage2.

Addressed reviewer comments.
Limited optimization to cases where the fixed called saved regs fit in the red zone of 288 bytes.

Modified patch to completely revert rL349512.

Patch is now only for Little Endian.
Big Endian will remain PIC by default as it was before. This is due to a bug found on BE where -fsanitize=leak is not detecting leaks correctly. As Little Endian is a higher priority we will add that code first and then look at the BE issue at a later date.

Patch is now only for Little Endian.
Big Endian will remain PIC by default as it was before. This is due to a bug found on BE where -fsanitize=leak is not detecting leaks correctly. As Little Endian is a higher priority we will add that code first and then look at the BE issue at a later date.

Added the PIC version to the second test as well.
Removed the third test. It has nothing to do with this change and I should not have modified that test in the first place.

@joerg
When you say that we produce quite bad position dependent code do you mean in terms of performance or in terms of correctness? At this point I have not seen any issues with the no-PIC code. If you have an example of this bad code please share the test case.
Also, changing the default option to no-PIC does not mean that everything we do will become no-PIC. For example, the way that the TOC is handled on PPC remains position independent. However, going from PIC to no-PIC does offer a number of opportunities (for example in in-lining).
With respect to PIE I'm not sure what the difference is between PIE and static relocation models in terms of code generation. Is there any reason why you would prefer PIE in this case? Do you have an example that shows it to be better than say no-PIC?

Generally the way I decided on how to update the test depended on a couple of things:

1. If the test had this line: ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py it means that we had an auto generate test and if I felt that the test had nothing really to do with PIC or no-PIC I would just regenerate it. For example a number of tests just had addis ld differences.
2. If the test was not auto generated but it still had nothing to do with PIC / no-PIC I would just add -relocation-model=pic. Changing these tests would not get us very much and it would be a significant amount of work.
3. For tests that had something to do with PIC / no-PIC I tried to make a judgement call as to what would be more useful to keep (the PIC test or the non-PIC test). If you feel that some of these tests I should have been the other way around let me know. I know you mentioned a couple in your comment and I'll take a look at those.

Default on all Power PC platforms is now no-PIC.
If any bugs are exposed by this change we will fix them as they are exposed.

Default on all Power PC platforms is now no-PIC.
If any bugs are exposed by this change we will fix them as they are exposed.

Simplified the code further.

Updated test cases.

Test cases updated.

Simplified some of the conditionals (easier to read) and added an early exit.