Originally, this patch is for helping another optimization (https://reviews.llvm.org/D30900). But potentially, removing duplication may affect other optimizations in general.
If you have a strong example to push this optimization, I think it is reasonable to submit a new patch with the description on how it improve the code with a large switch.

I forget to close this. The problem has been addressed by another patch https://reviews.llvm.org/D73653.
Thanks for all the comments.

• rebased to f6d6b98eec4

• make links to glossary in Tutorial and LangRef relative path.

@lucyrfox @mehdi_amini The relative links may not work if someone reads the tutorial directly on github since now Tutorial and Glossary is in the different repos. Is it acceptable?

@ftynse @jpienaar I got it. Thank you so much for the clarification.
Instead of adding Glossary.md in the repo, broken links to Glossary.md are replaced with links to https://mlir.llvm.org/getting_started/Glossary/

@mehdi_amini @stephenneuendorffer Thank you for the suggestions.

• remove cyclic dependencies among MLIR components.
• simplify add_mlir_library CMake function

• capture the name of symbols instead of using hard-coded names

@amyk I see. Please let me know you need some help.

BitPermutationSelector has been enhanced to generate better code for bitfield insert. So we do not need to specially handle bitfield insert anymore.
https://reviews.llvm.org/D49076

LGTM.
Thank you for finding the problem. I do not remember my intention on checking SeenUse here.

@AntonBikineev How about GCC Compile Farm? https://cfarm.tetaneutral.net/
Although I have never used it, the GCC Compile Farm provides access to powerpc machines.
I am sorry for the late reply.

@AntonBikineev When I revoke this patch on my machine, the problem is gone.
I somewhat digged into the problem, although I still cannot catch the true reason.

• The problem is caused in the constructor of __shared_ptr called from std::_Construct. The call chain for the _Construct is std::__uninitialized_construct_buf, std::__stable_sort.
• When I disabled EarlyCSE in the __shared_ptr constructor, the problem does not happen.

If a constructor is called from std::Construct, may this pointer potentially alias with other memory references?

@AntonBikineev It seems that this patch is causing failures in a ppc64 buildbot http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/ . Do you have any idea on the reason of the problem by looking at the errors?

gentle ping

@RKSimon Other colleagues in IBM are working on this and hopefully they will submit a patch separately. So I abandone this.
Thank you so much for your comments.

I'm just curious, is there something that runs after this pass that will clean up unreachable blocks if any became unreachable? For example, if MBB1 is the only predecessor of MBB2 and MBB2 is removed as a successor to MBB1, will something remove MBB2 afterwards.

Actually, no pass can eliminate unreachable block from this optimization. So I added a simple unrechable block elimination and modify a testcase for this.

add -verify-machineinstrs options in unit tests

@hfinkel do you have any further suggestions?

• rebased to the latest source (fix conflicts and update unit tests)

LGTM with nitpicking.

LGTM

Does this code pattern frequently happen?

rebased to the latest revision

This patch increases the number of record-form rotates we emit by more than 70%.

Do you mean reducing the record-form rotates by 70%? If so, it is great!

I added a missing dependency in CMakeFiles for ARCMigrate to fix build break in build bot (http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/)
https://reviews.llvm.org/rC340271

• check the explicit visibility attribute before changing the visibility to default
• add more tests

In D50968#1205958, @jsji wrote:

GCC option document mentions explicitly that local static variables should NOT be affected by -fvisibility-inlines-hidden.

Oh, thanks! I have not found this document.

gentle ping

In D49981#1185399, @hans wrote:

In D49981#1185396, @lebedev.ri wrote:

Just one: test/Transforms/NewGVN/pair_jumpthread.ll can now be un-XFAIL'ed i think?

I wonder if this still can be merged into 7.0, given that it is the second half of D48828/rL338485, which made it into the 7.0.
@hans ?

Sounds good to me.

Does the comment about normalization only pertain to ISA 2.07?

As I browse the document, neither ISA 2.07 nor 3.0 mention about normalization by xscpsgndp.
P8 UM says xscpsgndp, xvcpsgndp and fmr are normalizing instruction. P9 UM say nothing.
Since fmr is also a normalizing instruction, I feel it is acceptable to use xscpsgndp for coping register.

@spatel @lebedev.ri Do you have any further comments before committing this?

I submitted new patches for instsimplify to catch this opportunity.
https://reviews.llvm.org/D48828
https://reviews.llvm.org/D49981

XSCPSGNDP has longer latency (6 cycles) than XXLOR (2 cycles) on POWER8 while it has higher throughput with the same latency on POWER9. So XXLOR is preferable for pre-P9.

Please add/adjust the tests with baseline checks as a preliminary step; we don't want to lose those in case the code change gets reverted.

I have updated baseline checks.

• Separate the patch into two; this one is the first of the two.
• Add test cases with vector data type.

Yes, I'd also like to see the tests get committed now with baseline CHECKs.

I have committed unit tests in https://reviews.llvm.org/rL338107