[M68k] Fix reverse BTST condition causing opposite failure/success logic (#153086)

Given the test case:

```llvm
define fastcc i16 @testbtst(i16 %a) nounwind {
  entry:
    switch i16 %a, label %no [
      i16 11, label %yes
      i16 10, label %yes
      i16 9, label %yes
      i16 4, label %yes
      i16 3, label %yes
      i16 2, label %yes
    ]

  yes:
    ret i16 1

  no:
    ret i16 0
}
```

We currently get this result:

```asm
testbtst:                               ; @testbtst
; %bb.0:                                ; %entry
	move.l	%d0, %d1
	and.l	#65535, %d1
	sub.l	#11, %d1
	bhi	.LBB0_3
; %bb.1:                                ; %entry
	and.l	#65535, %d0
	move.l	#3612, %d1
	btst	%d0, %d1
	bne	.LBB0_3        ; <------- Erroneous condition
; %bb.2:                                ; %yes
	moveq	#1, %d0
	rts
.LBB0_3:                                ; %no
	moveq	#0, %d0
	rts
```

The cause of this is a line that explicitly reverses the `btst`
condition code. But on M68k, `btst` sets condition codes the same as
`and` with a bitmask, meaning `EQ` indicates failure (bit is zero) and
not success, so the condition does not need to be reversed.

In my testing, I've only been able to get switch statements to lower to
`btst`, so I wasn't able to explicitly test other options for lowering.
But (if possible to trigger) I believe they have the same logical error.
For example, in `LowerAndToBTST()`, a comment specifies that it's
lowering a case where the `and` result is compared against zero, which
means the corresponding `btst` condition should also not be reversed.

This patch simply flips the ternary expression in
`getBitTestCondition()` to match the ISD condition code with the same
M68k code, instead of the opposite.

0 files changed, 0 insertions, 0 deletions