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.

Sorry it took me so long to get back to this.
LGTM.

@gkistanova
Thank you for the review Galina.
I unfortunately don't have commit access to Zorg. Could you commit this for me?

Overall this looks good. I have a couple of very minor comments that can be fixed on commit.
LGTM.

The fix looks good to me.
However, I feel that the test is over-specified. What you are looking for is a rotate or a shift with an immediate of zero and to make sure that we can safely print those kinds of instructions to assembly. I feel that using the update_llc_test_checks.py script only produces a test that will fail when other changes are made later on and forcing the developer of that changeset to regenerate your test.

I like what this patch is doing. Overall, I only have some refactoring comments.

Added nit.

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.