Can you re-apply clang-format on AMDGPULegalizerInfo.cpp please?

A few nits / questions, otherwise LGTM.

LGTM

clang-format

It seems like this is breaking the LegalizerHelper.h / the LegalizerHelperTest:
/var/lib/buildkite-agent/builds/llvm-project/llvm/include/llvm/CodeGen/GlobalISel/LegalizerHelper.h:47:7: note: candidate constructor (the implicit move constructor) not viable: requires 1 argument, but 4 were provided
/var/lib/buildkite-agent/builds/llvm-project/llvm/unittests/CodeGen/GlobalISel/LegalizerHelperTest.cpp:641:19: error: no matching constructor for initialization of 'llvm::LegalizerHelper'

LegalizerHelper Helper(*MF, Info, Observer, B);

Somethign went wrong during applying the patch. Could you please have a look?
https://buildkite.com/llvm-project/diff-checks/builds/142783#01851b23-3226-4e98-bac5-219865bb07b5

Ping.
If this is getting too complicated, we could still think about moving to intrinsics.

Remove linter message

Added test to show the isDivergence behavior (copied from another test).
Changed run line to not test a specific architecture. This adds a few
s_movs to the lit tests, but shows the behavior of the isDivergence test
(the GFX10 behavior would be different).

Made comments more concise.

Moving constant check to visitExtractElementInst

Addressed review comments.

Don't access unreachable path when trying to constant-fold an extractelement with a select as index operand.

In D137934#3936962, @spatel wrote:

In D137934#3928765, @tsymalla wrote:

@spatel Thanks for adding these tests. These work in general, except the case where the second operand of the ExtractElement instruction is not a constant. The reason is that currently constantFoldOperationIntoSelectOperand expects both operands to be either the original select or a constant, but not an additional select, so a new extractelement instruction can be created to extract the actual value. If one of the operands is another select, it could be obvious that the sequence shows OOB behavior:

%e = select i1 %c, i32 3, i32 4
%s = select i1 %c, <3 x i32> <i32 2, i32 3, i32 4>, <3 x i32> <i32 5, i32 6, i32 7>
%r = extractelement <3 x i32> %s, i32 %e
ret i32 %r

Even if I know how to make the regular case work, I'll wrap my head around that particular issue.

Just bail out if the extract index value is not an immediate constant? The case where the index value is a select-of-constants that can be reduced might be another patch, but that doesn't seem like a common pattern.

@spatel Thanks for adding these tests. These work in general, except the case where the second operand of the ExtractElement instruction is not a constant. The reason is that currently constantFoldOperationIntoSelectOperand expects both operands to be either the original select or a constant, but not an additional select, so a new extractelement instruction can be created to extract the actual value. If one of the operands is another select, it could be obvious that the sequence shows OOB behavior:

Fix assertion failures

Removed the whole custom implementation as InstCombine is already able
to do the constant folding, but the Visitor for extractelement needs an
additional check to prevent folding the constants into select operands
when the select uses a condition vector.

In D137934#3926911, @foad wrote:

You don't need your new function FoldExtractElementSelectConstVector at all. All you should need to do is to call FoldOpIntoSelect from visitExtractElementInst, and add (trivial) support for ExtractElementInst in foldOperationIntoSelectOperand. For example: https://reviews.llvm.org/differential/diff/475368/

Remove superfluous dyn_cast for getAggregateElement.

Remove OOB logic. Simple cases will be handled earlier, so the relevant code
path will not be visited.

Update lit tests.

Add additional test to show folding for other types.
Use Constants instead of ConstantInt.
Conditions must be Integer types, no vector types.

In D137934#3925091, @spatel wrote:

This is missing at least one critical pattern-matching constraint (and regression test - because this will crash):

define i32 @extelt_vecselect_const_operand_vector(<3 x i1> %c) {
  %s = select <3 x i1> %c, <3 x i32> <i32 2, i32 3, i32 4>, <3 x i32> <i32 5, i32 6, i32 7>
  %r = extractelement <3 x i32> %s, i32 2
  ret i32 %r
}

• Move logic to FoldOpIntoSelect.
• Remove superfluous use check for the extractelt instruction.
• Make use of early returns.
• Add more / fix existing comments.

In D137934#3924774, @foad wrote:

extractelt (select %cond, <vec1>, <vec2>), %c1, %c2 ->
select %cond, <vec1>[c1], <vec2>[c2]

What are %c1 and %c2? Surely these is only one index?

Also your description does not make it clear that you are only doing this for constant vectors. For general vectors it could be: extractelt (select %cond, <vec1>, <vec2>), %c -> select %cond, (extractelt <vec1>, %c), (extractelt <vec2>, %c)

In D137934#3924785, @nikic wrote:

Can we extend FoldOpIntoSelect to handle this instead?

Fixed error on Windows build and whitespace issues.

This change handles most of the tree structures, but not
all of them, because this would add way more complexity.

Re-structure loop once again.
Operands can now be on arbitrary positions.

Fix the lit tests.
The restructuring of the main loop caused issues, because now it was
also possible that the the top-level OR (the one passed to selectV_BFI)
is matched, which is not intended here.

Change the structure of the main fetching loop.

Only require single uses on nested ORs

Add use checks.

Addressed review comments.
Simplified code and fixed comments.

In D136432#3873908, @jsilvanus wrote:

I see, thanks!

So Select_BFI just implements special case handling of BFI matching with more complicated expressions that we can still work with (because selectors are constants), and the default case is handled elsewhere.
Maybe we should rename Select_BFI to reflect that?

In D136432#3873879, @jsilvanus wrote:

As such case cannot be combined into a BFI instruction, I guess it's relatively straight-forwardly translated into something like this:

Why can't we, isn't this essentially the definition of BFI?

In D136432#3873859, @jsilvanus wrote:

One inline comment on a comment :).

Slightly related: How do we handle (X1 & Y) | (X2 & ~Y) where Y is a variable?

In this specific example, visitMaskedMerge for xor InstCombine tries to combine the xor, and, xor pattern as long as both xor instruction use the same operand. This works for the first xor, and, xor sequence, but changes the IR in such way that the second xor, and, xor sequence (which depends on the result of the first one) cannot be matched anymore even if it could before. This prevents the second v_bfi from being generated.
I will abandon this change and try to generate the canonical form earlier.

In D134418#3833436, @foad wrote:

I don't immediately see how shifts are relevant.

For the basic case of nested bitfield inserts, perhaps you could create tests for the cases you want to handle. For example, IR equivalents of:

1. (x & y) | (~x & z) // single insert
2. (x & y | (~x & ((u & v) | (~u & z))) // nested insert
3. (x & ((u & v) | (~u & y))) | (~x & z) // nested insert

For the nested inserts we might want separate test cases depending on whether the "select" arguments x and u are known to be disjoint or not. E.g. 0x0F and 0xF0 are disjoint, 0xFF0 and 0x0FF overlap, and for non-constant values we don't know whether they overlap or not.

Update pattern matching to include a shl instruction.
Describe a case where such pattern can occur.

Added DivergentBinFrag class to outermost node.
Fixed comment.