Fix signedness handling of any_extend

In D159533#4649980, @foad wrote:

@jrbyrnes shouldn't we land the AMDGPU changes separately first? Or would it all be dead code without the rest of this patch?

Fix dereference issue + nits (reorganize logic + comments)

Extract signedness checking

Thanks -- the AMDGPUISD::PERM side LGTM

Can you please bring in tests from https://github.com/llvm/llvm-project/pull/66965

Disregard previous version of comment -- I did not see the most recent changes.

what is the best way to generalize the performOrCombine handling to support ISD::FSHR as well?

IsSigned tracks whether or not to produce an instruction with signed behavior. In some cases, we are able to determine this based on the semantics of the top-level instruction, however, in other cases, we need more information. For such cases, we must look to the tree itself.

Bring in https://github.com/llvm/llvm-project/pull/65995

Reopen for review as it has been reverted, now includes https://github.com/llvm/llvm-project/pull/65995

Abandon in favor of https://reviews.llvm.org/D155995

Abandoning since rules provides framework for closely fitting pipelines to user specifications.

Reopened due to commit reversion

Address comments + Add tests & change test structure of vni8-across-blocks

Address comments

ping

Account for max scalar size of i256. Factor out common code.

Thanks, LGTM

Address Comments

Include comments about dot*c, remove unintended changes to test

Add note for intrinsics

In D155868#4614117, @arsenm wrote:

This is better than the combiner - if it doesn't completely blow up compile time. It's probably easier to avoid the compile time problems with the combine though

Rebase (for https://reviews.llvm.org/D158468) and lower with intrinsics.

Properly handle neg modifier

We have since taken the UI for this framework in a different direction. Most of what can be achieved through this UI can be achieved with already existing controls / interface (e.g. SGB). I don't see any need to pursue this further, will reopen if there are opposite opinions.

Clean up getBitcasted* implementations

Fix non-determinism -- iteration order of DenseMap. Use SmallVector instead (worst case lookup is non factor due to size)

f76ffc1f406ecdb5a8329e8a10a56f0ce2f6220c

Rebase + clean up code. Still running tests but no longer a WIP.

Naming + function API

Add getExtOrTrunc for Any/Z/S.

RegUnitsToInvalidate

Convert RegsToInvalidate back to MCRegister as well.

Delete partial conversion to regunits

Always try to invalidate both the LastSeenUseInCopy and CopyInfo->MI.

Use LastSeenUseInCopy + use regunits in more places.

In D157564#4575259, @lkail wrote:

5: USE r6
6: r1:4 = COPY r6:9

Hi @jrbyrnes , do you know why MCP fails to invalidate r7:r9 at label 5? In my view, when we are invalidating r6 at label 5, we should also find the copy involving def or use of r6 which is label 6, and invalidate the regunits of both src operands(r6:r9) and dest operands(r1:r4), which is what invalidateRegister doing.

          RegsToInvalidate.insert(
              CopyOperands->Destination->getReg().asMCReg());
          RegsToInvalidate.insert(CopyOperands->Source->getReg().asMCReg());
...
    for (MCRegister InvalidReg : RegsToInvalidate)
      for (MCRegUnit Unit : TRI.regunits(InvalidReg))
        Copies.erase(Unit);

Fix Extract element id handling

Remove remaining redundant code.

Address comments + remove redundant ValueSize checks and handling

Rebase + Extended algorithm for more complete coverage of potential trees.

SLP vectorization should be tuned but that seems like a separate issue. Trees corresponding to v_dot4 often have s/zext as the final dest is 32 bit, but the arithmetic operations involve 8 bit operands. By introducing s/zext into the tree, we confuse the SLP vectorization cost model as it thinks it is vectorizing 32bit operands. The main issue is that cost model only looks at one node of the vectorizable tree at a time to calculate cost, instead of also considering the sequence as a whole. If we were to vectorize, codegen may be significantly less complex for these.

Nothing necessarily planned at the moment, just want to block the review for now.

passes psdb

Address comments + rework "hasEightBitAccesses".

Fix some errors.

Will abandon if https://reviews.llvm.org/D155995 supersedes selection of these instructions.

In D155868#4519802, @arsenm wrote:

In D155868#4519799, @arsenm wrote:

We used to pattern match all the dot operations, but stopped because of a ridiculous blow up in compile time. Have you tried measuring that?

Also look at the generated selection tables. This shouldn't be one of the first patterns tried