The miscompile case's G_ZEXT has a G_FREEZE source. Similar to D127154, this patch removed isDef32, relying on the AArch64MIPeephole optimizer to remove redundant SUBREG_TO_REG nodes also in GISel.
Fix #58431
Differential D136433
[GlobalISel][AArch64] Fix miscompile caused by wrong G_ZEXT selection in GISel bcl5980 on Oct 21 2022, 2:07 AM. Authored by
Details The miscompile case's G_ZEXT has a G_FREEZE source. Similar to D127154, this patch removed isDef32, relying on the AArch64MIPeephole optimizer to remove redundant SUBREG_TO_REG nodes also in GISel. Fix #58431
Diff Detail
Unit Tests Event TimelineComment Actions I think the bug is that GlobalISel is emitting SUBREG_TO_REG, not that it's getting eliminated later. See https://reviews.llvm.org/D127154 . Comment Actions Maybe GlobalISel should stop using isDef32, like we did for SelectionDAG? I mean, this fix isn't really wrong, but I think we have the same general issue as SelectionDAG; it's hard to tell how a generic operation is going to be lowered before it's actually lowered. Comment Actions Yeah I agree. I don't have anything setup to test Global ISel, and we don't have the same breadth of lit tests, but I hope that it is similar to Selection DAG where the later peephole optimizations are enough to remove the extra instructions. Comment Actions I don't think the usage in selectArithExtendedRegister actually needs to work reliably for correctness; the pattern doesn't assume anything about the high bits, and if we don't use the pattern, we just fallback to a normal zext. So it doesn't really matter that much. (See also the SelectionDAG version of this check in AArch64DAGToDAGISel::SelectArithExtendedRegister.) Ideally, I guess it would look through freeze instructions. Or maybe we should just never match "uxtw" during isel, and just add something to AArch64MIPeepholeOpt. In any case, let's fix the miscompile, and leave it for later. Patch looks fine, but this should be approved by one of the AArch64 GlobalISel maintainers. |