This is only better if this is fed by a compare you can invert. This should probably not do this if it finds some other i1 def.
We also should probably check if the inverted condcode is legal, but I guess we're missing cond code legality infrastructure (and none of the targets with gisel now don't need it)
This is illegal, you can just assume these are registers
We process the whole expression tree and return false if we find anything that is not an AND or OR or a comparison.
A MIR-esque example would be handy here, just to make it explicit what's being matched.
I don't think here's any reason to talk about an index I here; from the looks of it, the below loop can be a range-based for?
Usually people assert that the result of MRI.getVRegDef(...) isn't null.
I'm not sure if that's actually necessary in this case though; I *think* that it can only be null when you have a physreg, but I'm not entirely sure.
A MIR-esque example would be useful here too?
No, it's slightly tricky. It can't be a range-based for because we push more stuff into RegsToNegate inside the loop. It's a worklist algorithm, but without using a separate worklist vector.
Right, the xor is introduced by IRTranslator::emitSwitchCase. Perhaps it could be optimized at that point, instead of later in a combiner pass, but I'm not sure how feasible that is. I guess at that point you can't do accurate hasOneNonDBGUse checks?