Two nits inlined. Otherwise this patch looks OK, eyeballing the supplied test.

Some post commit remarks.

LGTM.

In D66228#1632790, @Petar.Avramovic wrote:

...
What difference does SYM_32/SYM_64 make, all selected instructions use only 16 bits of something that is resolved later?

In D66228#1635859, @atanasyan wrote:

Thanks for review. Could you clarify some points in your comments?

In D66228#1632060, @sdardis wrote:

The correct approach I believe is to fix the SYM_32 bug, then provide the patterns for cases of where intermediate/end nodes such as MipsHi / MipsLo can appear without an add appearing as their parent node.

1. If we do not change the getAddrNonPICSym64 function, at some point (before lowering) we anyway(?) get the following chain of commands (add (shl (%hi(sym), 16), %lo(%sym)). How can we lower it to a correct set of instructions, if we do not have a pattern with the shl? Please correct we if I'm wrong.

I took a second look, and I believe this patch is the incorrect solution. The bug actually lies in the implementation of PredicateControl and SYM_32/SYM_64, @Petar.Avramovic nearly spotted it.

This looks OK to me, I'd like to take a hard look at what DAGCombiner is doing here.

LGTM.

I've raised some points inline, I think (a) is most relevant to this patch but shouldn't stop it going forward but should be addressed quickly, (b) and (c) could be noted as TODO:s.

In D48069#1479260, @beanz wrote:

Is there a specific version range of GCC that this miscompile occurs with?

I think this is a viable approach for this issue. Based on the dumps from -debug I can see that the backend should only be selecting even register for FGR32.

My initial comments are that this looks ok, but I would like a longer look at it.

Good catch. LGTM.

One nit inline, but otherwise LGTM.

Some minor nits inlined, but otherwise the patch is more or less there.

Two comments, and some more inlined. Check the formatting of the commit message
body, it should be 80 cols max. Otherwise the log messages can look strange due
to wrapping (I'm using git).

Sorry I didn't spot this earlier, but in future please ensure 'llvm-commits' is one of the subscribers when creating a review request for LLVM. If you add it after creating a review request, manually add it and write something in the comments field to trigger Phabricator into sending an email or abandon the review request and re-open it with the relevant -commits list as an initial subscriber.

LGTM apart from some minor nits. Please address them before committing.

In D57718#1393615, @Carrot wrote:

In D57718#1393504, @jsji wrote:

Any testcases that can show the problem and test the fix? Thanks.

It can only be triggered by a very large (>32KB) function body because the range of conditional branch is +/- 32KB.

In our case, the large function body is caused by aggressive thinlto guided inlining.

So no small test case can demonstrate the problem :(

I can't find rationale behind the MIPS discrepancy in the original commit. I can add the if branch back if you tell me why...

LGTM. Just remember to upload the patches with context.

Ping.

Ping.

Address comment.

Ping.

Looking at this again and with trunk, I'm seeing two failing tests with a small change inlined:

Added tests, and corrected the definition of the rdhwr instruction.

Actually include the expansion pass.

Moved pass to after the scheduler and machine block placement.
Normalized the probabilities for the successors of modified basic blocks for sanity purposes.

In D47829#1124040, @efriedma wrote:

Is this something which is actually useful to control? From your description, you want to add the flag to clang not because you actually want to use it, but just because you can't figure out how to pass the right flags to your clang build.

If it is useful, it should be implemented as a function attribute, not a global flag.

Modify implementation to produce a function attribute.

LGTM with nit addressed.

Rebase to master.

In D48006, you can see the change for the MIPS specific assembly scrubbing to accept inline assembly. I have also included some example output of the changes of that revision. Since the blank lines around the inline assembly are not scrubbed, FileCheck fails the test case with:

Ping.

Ping.

Please rebase this.

Actually add some tests.

Add tests.

Edit the summary so that rather that it says:

LGTM.

The legalization of unsigned i128 addition (rL334094 for the test) looks strange to me in that the determination of the overflow from the first addition is done with setccs. They appear to be originating from the expansion of setcc of an illegal type.

This particular case is not quite testable, as GPR64s are only available when we have 64 bit registers. Adding GPR_64 predicates to these instructions is somewhat overkill, but does simplify fixing up the scheduler models later.