Moved foldToImm into SIInstrInfo as suggested
Implemented check in verifyInstruction and checked that it worked when the fix was removed

Added missing break

De-duplicated 1/2PI constant

Made suggested change

Made suggested changes

Folded in most of the changes highlighted in the review

Looking again at the code - you're correct that it attempts to only do this transformation if the high bits are zero.
However, the code that checks this has the following telling comment:

LGTM - but you might want further reviews from others not so involved in implementation.

@nhaehnle - just added you as reviewer at the moment.

D48555 supersedes this change.

Yes, this change looks better based on what you say about not requiring live-in's for undef sub-ranges.

Removed test as being overkill for the missed state clear being added (2 other
tests still remain)

In D45372#1068792, @alex-t wrote:

In D45372#1068728, @dstuttard wrote:

2. Remove the test altogether since the VirtReg2Value.clear() is definitely required and was originally missed as an oversight - and the test might be overkill.

Sounds reasonable. It really was an oversight :) It's funny that the change was reviewed by lots of people for 2 months but nobody noticed not clearing state.

In D45372#1062947, @alex-t wrote:

In general LGTM.
I also concerned about the magic test that has no checks and has no visible side effects on shared data but is necessary to reproduce buggy behavior.
Could you please clarify what do you need it for?

Folded in triple to run line

LGTM

Any comment on this change? If not I'll land in the next few days.

Any comment on this change? If not I'll land in the next few days.

Any more comments on this change? If not I'll land this in the next few days.

Removing a debug llvm_unreachable

A better fix for this problem.

The intent of this code is really to allow anyone doing debug to insert a check anywhere in the code. In particular, for the problems I was looking at I needed to check the live intervals after each change made in order to pinpoint where an error was being introduced. As implemented here (with the check after coalescing) it looks redundant, so having that extra check is probably useless.
Running a verification phase after coalescing is sometimes too late, and indeed may well have asserted before this point.

Removing debug code

I'm going to take another look at this bug.
I've also uploaded a couple of other fixes for SubRange join failures. See D40300 and D40308. I've also uploaded a verifier method that is helpful in tracking these problems down. See D40297.

Removed a blank line causing unnecessary differences

I've got a couple of new SubRange join fixes that I'm about to upload for review. This routine was useful in tracking those down so I thought it would be useful to add as a generic aid for future problems.

In D35241#891440, @RKSimon wrote:

@dstuttard Are you ready to commit this?

Test now reduced further - thanks @RKSimon - confirmed that it still exhibits the problem and that the fix still fixes it.
I managed to remove a couple more lines from the cut-down version you provided.

Cutting down the test size and rebasing

In D35241#871886, @RKSimon wrote:

@dstuttard Are you still looking at this?

In D35241#827823, @arsenm wrote:

Can you reduce the test any further?

Agreed - @cwabbott your changes provide something much more complete than this change, plus remove the need for it. Thanks.

In D34889#815492, @MatzeB wrote:

Testcase? It seems that your change wants to allow the following:

vreg4:sub0<def, dead> = ...
...
  = use vreg4:sub1

This is not legal! The dead modifier is about the full vreg not just about the sub0 part defined. (-verify-machineinstrs should also lead to such inputs getting rejected).

Implemented a slightly different approach to resolving the issue.

In D35073#815414, @MatzeB wrote:

I'm confused by this change (and the testcase doesn't really help understanding what is going on). You are probably onto a real bug here where we cannot assume the same lanemasks work for the input/output register class of a copy. However that should be independent of the fact that a full or partial copy is present.

ping

ping

@arsenm - any comments?

It's already bugpoint reduced - I tried trimming it further by hand but it hid the issue (unsurprisingly).

Not sure who is an appropriate reviewer for this, adding @RKSimon as he seems to have made several changes in the same area.

Adding verify-machineinstr flag to llc invocation in the test

I do have a reproducer for this (a .ll test). I've attempted to turn this into a .mir test, but it is too fragile to allow me to change the target specific intrinsics to something generic (required in order to print out the .mir).
Hopefully, the check is an obvious omission and an easy one to approve?
If not I'll see if I can create a smaller regression for it - but I've already spent quite a lot of time attempting to do this.

Updating the test to a .mir test
Replacing the buffer.load intrinsics with load volatile worked

@qcolombet - any further comments or are you happy for this to go in?

In D34391#791480, @MatzeB wrote:

The code fix LGTM, but please wait for @qcolombet/@arsenm before committing.

Making a .mir test seems indeed hard at the moment, as the printer already fails; manually stripping memory operands only works after printing I presume?

I think we will require a more extensive change to properly support WQM and all it can do. However, this is a minor extension to an existing intrinsic that allows implementation of functions required in some shader implementations.
This can be removed if necessary if more fully featured support is implemented.