[llvm] [AArch64][GlobalISel] Select G_ICMP instruction through TableGen (PR #89932)

David Green via llvm-commits llvm-commits at lists.llvm.org
Wed Apr 24 09:26:00 PDT 2024


================
@@ -5376,6 +5376,51 @@ def : Pat<(AArch64bsp (v4i32 V128:$Rd), V128:$Rn, V128:$Rm),
 def : Pat<(AArch64bsp (v2i64 V128:$Rd), V128:$Rn, V128:$Rm),
           (BSPv16i8 V128:$Rd, V128:$Rn, V128:$Rm)>;
 
+multiclass SelectSetCC<PatFrags InFrag, string INST> {
----------------
davemgreen wrote:

I'm not sure what the reason for using CMEQ etc nodes is - it might be that they were protecting against producing invalid nodes later in the pipeline (if at the time there was not a way to control DAG from re-creating a "setcc ne", which couldn't as easily be selected). It might be that the return type was not reliably treated as all-ones/all-zeros. Maybe it's just always worked like that because that's how the Arm backend worked previously.

It creates a lot of nodes - both for CMEQ/CMGE/CMGT/CMHI/CMHS and for the nodes that compare against zero CMEQz/CMGEz/CMGTz/CMLEz/CMLTz. And keeping nodes target-independent for longer can be a benefit. We are hoping we can avoid all of that and just use G_SETCC directly with some new patterns to replace the selection code. With the current way this works we will just need to be careful about not introducing a "setcc ne" after legalization without checking with the target that it is a supported operation.

@chuongg3 has tested some CMEQz and they were appearing to work OK too, to be added in a follow-up patch. So long as we are OK with not introducing "bad" setcc's after legalization then this patch seems OK to me.

https://github.com/llvm/llvm-project/pull/89932


More information about the llvm-commits mailing list