The idea is great! Some comments.

Abandon this revision, as most opportunity has been fixed by https://reviews.llvm.org/rL202451.

No. I didn't have the requirement to customer to cpu for the scheduler yet. I will abandon this patch and we can add the feature if we indeed find some cases that to do the customization.

In D64198#1570920, @jsji wrote:

As Hal mentioned, enable-misched and enable-post-misched should be able to turn on/off the pre-ra/post-ra scheduler.
Regarding to different subtarget (cpu), why we need to turn on/off with feature at runtime? Shouldn't that be configured in code?

yeah, per function control might be more useful here.

I am sorry that, I didn't put enough background for this change. The idea is not for per-function basis. We have the pre-ra scheduler and post-ra scheduler you know, and they should be able to be configured for different CPU processor. (Some cpu might need the post-ra scheduler, and some didn't, though we always enable it for all cpus) This is done by adding features and included by different cpu. And it also gives us the ability to turn on/off the specific scheduler.

LGTM, with one minor comments. Maybe, you could commit a NFC patch to use "|=" instead of "=" to set the Simplified flag.

As talked, please confirm why we didn't set the Simplified flags. FWIK, this is a flag to indicate that, we have done some changes. We should set it.

Hi, @hfinkel
As this was added by you in https://reviews.llvm.org/rL202451, would you please help me review this patch ? And I also commit another patch(https://reviews.llvm.org/D63318) to fold this pattern in DAGCombine. Would you please take a look together ? Thank you!

Update the comments.

As the X86 review is done (Another issue exposed by this patch, and x86 backend will work on that ?), let's continue the review for the PowerPC backend and DAGCombine logic.

Add the isZextFree check.

In D61250#1545597, @fhahn wrote:

Would it be possible to add a test where the forwarding kicks in?

Address reviewer's comments. Thank you!

Address reviewer's comments.

• Move the ctor to the header.
• Declare the SchedState as "class" instead of "struct" (Is it ok?).
• Rebase the patch to master and resolve the conflict.

LGTM

recommit the patch https://reviews.llvm.org/D61843 together with this one.

@RKSimon Thank you for your nice review!

Address comments. Early return if it has been set before, to make the code more robust.

We cannot have the assertion, as it is possible that, it isn't set to something else(for example, this case). And the isBigEndian() check will fail if it isn't set to something else. However, in fact, we could do a check for each element, early return if it isn't set.

I have created the patch https://reviews.llvm.org/D62897 to fix this issue. @sbc100 Do you have any step for me to reproduce the broken ? I tried the c code you mentioned, didn't see the difference. And it would be great if you could try the patch of https://reviews.llvm.org/D62897 together with this one to see, if the broken fixed.

I have never used the children-parent before. I just add it as parent revision now, no more action. This is what I want to do:

1. commit this patch.
2. rebase the parent revision patch and commit it. (I need to update the patch for that revision in theory)

I will hold this patch until the test case update for systemZ is accepted. D62370: [NFC] Check the endianness after the CodeGenPrepare.

Address comments.

Hi @jonpa
As https://reviews.llvm.org/D61843 is approved but blocking by this patch, would you please help me review the change ? Thank you !

Yes, I tried but decide not to reuse it. Because, the load pattern is trying to find out the load sequences that they are SHIFT and OR together, so, they have to walk the tree recursively to collect all the loads. But the store pattern is much easier. Because, We already know the stores from the chain. What we need to do is to check if all the store values are from some fixed pattern.

Gentle ping ... Thank you!

https://reviews.llvm.org/D62370 is created to update the test llvm/test/CodeGen/SystemZ/codegenprepare-splitstore.ll

LGTM. But please hold on for some days if someone else might have comments.

Address jinong's comments.

Gentle ping ... Thank you!

LGTM, except some minor comments. However, please hold on for some days, if others have comments.

FYI. This is the thread of the discussion. http://lists.llvm.org/pipermail/llvm-dev/2016-September/105291.html

That was discussed widely when https://reviews.llvm.org/D26149 is reviewed. This is the commit log saying something about the delay.

This optimization was discussed on llvm-dev some time ago in "Load combine pass" thread. We came to the conclusion that we want to do
this transformation late in the pipeline because in presence of atomic loads load widening is irreversible transformation and it might hinder other optimizations.

Gentle ping ...

ok. Use the hasValue instead of the implicit bool convert operator to make the code clear.

Update local variable name.

Address comments.

Use opt instead of llc to do the check.

In D61169#1481670, @dmgreen wrote:

Hello. I feel like this splitting just shouldn't be done for volatile stores.

@fhahn I have completed all the needed patches, and it would be great if you have the time to continue the review. This is the whole picture.
https://reviews.llvm.org/D61248 is the 1st patch to allow the schedule strategy to forward the schedule state between MBB.
https://reviews.llvm.org/D61249 is the 2nd patch to update the schedule strategy for SystemZ target to adapt with 1st patch.
https://reviews.llvm.org/D59480(this patch) is the 3rd patch to add the scheduled state data structure, so that, it could be kept somewhere.
https://reviews.llvm.org/D61250 is the last patch to forward the scheduled state 3rd patch added for PostGenericScheduler and enable it for PowerPC target.

Update the patch according to the reviewer comments.

I am ok now for the doc part change. Thank you.

Looks good, just one minor comments.
It seems that, we have already had the PowerPC section in the rst. It would be better to put them together.

PowerPC Language Extensions
------------------------------

It would be great if we could add some documentation for these new added builtins, to make more people to know what we have done. i.e. clang/docs/LanguageExtensions.rst

ok. I will prepare another two patches first, so that, we could continue the review.

Thank you for the review comments. I have addressed all the comments.

gentle ping ...

Address comments.