Rebased, changed strictwqm to strict_wqm and updated tests.

Added missing dot in the intrinsic name.

Rebased and updated tests.

Looks go to me (with two nits inline).

Commoned up the SI and GFX10-WAVE64 checks.

Updated commit message with more details and pasted the original error message.

Tests rewritten.

Add the underscore between strict and wwm. Restored the old tests for amdgcn_wwm.

This is the intended patch, no need to change AMDGPUISelDAGToDAG.cpp in the most recent version. Here, due to the updated check in isBoolSGPR the problematic combines that would strip zext will not happen (see SITargetLowering::performAddCombine/performSubCombine). This is similar to the very first approach I put up for a review.

Following the suggesstions of updating isBoolSGPR.

Is it worth adding a test to ensure old intrinsic still works?

See also D96258.

LGTM with a few nits - feel free to ignore them.

Thanks!

Sorry for the lack of activity lately - I plan to get back to this patch in the near future.

LGTM with a few more nits (inline).

I asked myself the same question - this was tried before - see https://reviews.llvm.org/D24544. I do not know any more details.

Added two more instructions: trunc and freeze (thanks @foad).

As Matt pointed out in D91633, extractvalue and insertvalue were also missing, so I am adding them here (the new tests are taken from D24543). Also the tests added earlier in D91633 are being moved to spec-other.ll.

Rebased to retrigger the buildbot checks.

Ping.

In D80485#2342195, @amyk wrote:

In D80485#2341858, @piotr wrote:

Hi! This commit causes problems for AMDGPU backend - see attached file

repro.ll1 KBDownload

. Any ideas before I start investigating this in detail?

LLVM ERROR: Cannot select: t56: i16 = mulhs t42, Constant:i16<-32509>

t42: i16 = truncate t67
  t67: i32 = add t66, t28
    t66: i32 = add t37, t34
      t37: i32 = shl nuw nsw t12, Constant:i32<13>
        t12: i32,ch = CopyFromReg t0, Register:i32 %5
          t11: i32 = Register %5
        t36: i32 = Constant<13>
      t34: i32 = shl nuw nsw t10, Constant:i32<7>
        t10: i32,ch = CopyFromReg t0, Register:i32 %4
          t9: i32 = Register %4
        t26: i32 = Constant<7>
    t28: i32 = add t16, t27
      t16: i32,ch = CopyFromReg t0, Register:i32 %7
        t15: i32 = Register %7
      t27: i32 = shl t8, Constant:i32<7>
        t8: i32,ch = CopyFromReg t0, Register:i32 %3
          t7: i32 = Register %3
        t26: i32 = Constant<7>
t52: i16 = Constant<-32509>

Hi, I agree with the suggestion by @dmgreen. Could you see if that works?

Hi! This commit causes problems for AMDGPU backend - see attached file

Related to D78091.

Renamed variable to avoid a multiline assignment.

Good spot - I looked at the shader database and indeed the pattern with two connected setcc is frequent enough to special case it so I updated the patch.

Invert the condition.

Ah now I see what you meant, sorry.

Ping.

Simplified test and added 5 more.

In D87882#2282886, @rampitec wrote:

In D87882#2282818, @piotr wrote:

In D87882#2282278, @rampitec wrote:

Doesn't loop block self dominate?

You mean, why the condition "MDT.dominates(From, To)" returns false if From and To are in the same BB? Inside that function there is a bb dominance check if the instructions are in different blocks, but if the instructions are in the same block the code checks whether From comes before To.

The bug I am trying to fix is simplified in the test m0-in-loop-0 where before my patch SI_INIT from line 333 was incorrectly removed. Although "m0 = COPY" comes after SI_INIT in that bb, this is a loop and in the second iteration DS_WRITE would see a clobbered m0, so SI_INIT has to be preserved.

That sounds like a bug in the dominate() to me.

In D87882#2282278, @rampitec wrote:

Doesn't loop block self dominate?

I think you are right - I moved the fix to the better place.