Allow patterns to explicitly ask to look through copies.

In D87456#2267858, @foad wrote:

This will be fixed by in D87511.

Wouldn't it make more sense to change the order of the patches in the stack so that D87511 is applied first and this one is rebaed on top of it?

Move change in IRTranslator in another patch, since effects of that change can only be seen when function attributes are inspected during translation of a function that was not first in input file.
Move check for NoNaNsFPMath in isKnownNeverSNaN.
Reduce number of tests, only keep characteristic ones that will be updated when we add some combines and improvements to legalizer. Later switch to existing test in sdag that also checks for pattern commutes.

Add assert for StoreIdx.

Factor string generation of operand names into function.

min3/max3 patterns are handled in combiner, inducing med3 patterns with constants. Patch imports med3 isel patterns: min(max(a, b), max(min(a, b), c)) but they need some combines/legalize fixes to be selected. From new imports only V_FRACT can be selected at the moment.

With G_FCANONICALIZE out of the way, we can now select some of the med3 patterns that were imported in D87351.

Add more verbose comments, and switch to std::array as container for operands.

Show how this emitter change affects isel, and update tablegen tests.
Add additional checks for complex suboperands for test added in D57980. Neither tablegen nor sdag have check for such pattern and it looks like an error to me (there is no way for tablegen to know that some c++ code that generates two operands will generate same operand x (first out operand) from different input operands - these are operand 1 and 2 of G_ADD instruction). Also, if I checked correctly, there were no patterns like that in llvm upstream. Skip such patterns anyway in GlobalIselEmitter.

Move support for predicate code that uses operands to a separate patch.

Attempt to teach emitter to collect operands that predicate with 'let PredicateCodeUsesOperands = 1' requires.

Force promotion to 32-bit first when subtarget doesn't have 16-bit instruction.

Addressed review comments.

Switch to custom lowering and update to match changes in dag custom lowering for frem (and use same lowering for s16 also).

@hans, could you please commit this patch for 11.x release?

might be worth to include this also for the 11.x release.

What is the procedure for that?

Remove else branch.

Would it make more sense for narrow scalar to widen to the next multiple of 32 itself?

Probably yes, at least for add, sub and mul. It could calculate required scalar size and call widenScalar instead on reporting UnableToLegalize.
I am not so sure if this would be correct in general, maybe some opcodes prefer next-power-of-2 instead of multiple of NarrowSize?

Preserve flags, and use G_INTRINSIC_TRUNC.

This update also simplifies f16 -> i64 on subtargets without has16BitInsts().
Such targets immediately promote f16 to f32 whenever they encounter f16 def using fp16_to_fp node. Recognize fp16_to_fp input to f32 to i64 and do the same thing as for f16 to i64 conversion. This gives similar(small difference for f16 vectors) results for subtargets with or without has16BitInsts() since f16->i32 gets selected like f16->f32->i32.
Update tests with more detailed checks.

Context was missing.

Split G_FPEXT in legalizer. This could also be widenScalar for TypeIndex == 1.

This might be narrowScalar on TypeIndex==0 but it requires that s16 is at TypeIndex==1 thus I used custom legalize.

Remove tests with preassigned banks, use icmp to produce vcc freeze. Add liveins to functions that didn't have them.

Move isValid check on top.

Add a few sgpr,agpr and vcc tests similar to ones from regbankselect-copy.mir. Original tests were from legalize-freeze.mir

This fixes assert and makes this test mentioned in D82651 to fallback for aarch64.
This seem to have different handling on different targets. I don't know what is the best way to handle this since it looks to me that custom handling has to be done in different places
Just adding same flag and register as MatchedOperand works for this example but from this comment

I see. I expected that reg class was already determined when previous operand was processed. I will take a look, first operand should have probably asked TargetRegisterInfo for PointerRegClass.

Replace assert with isel fail.

Added tests for matching constraints that involve sgpr. Also added one more test file with comparison between 'register class constraint' and 'matching constraint' in final asm output.