[PATCH] D145220: [X86][InstCombine] Simplify some `pternlog` intrinsics

[Noah Goldstein via Phabricator via llvm-commits]

goldstein.w.n added inline comments.


================
Comment at: llvm/lib/Target/X86/X86InstCombineIntrinsic.cpp:585
+
+  bool ABIsConst = isa<Constant>(A) && isa<Constant>(B);
+  bool ACIsConst = isa<Constant>(A) && isa<Constant>(C);
----------------
craig.topper wrote:
> Do we need to make sure we are looking at vectors of ConstantInts rather than vectors of ConstantExpr?
Will the ALU not fold with `ConstantExpr`? How can I test that?


================
Comment at: llvm/lib/Target/X86/X86InstCombineIntrinsic.cpp:588
+  bool BCIsConst = isa<Constant>(B) && isa<Constant>(C);
+  bool ABCIsConst = isa<Constant>(A) && isa<Constant>(B) && isa<Constant>(C);
+
----------------
craig.topper wrote:
> craig.topper wrote:
> > If everything is const can we someone use the immediate as a lookup table instead of manually describing every case?
> somehow* not someone
> If everything is const can we someone use the immediate as a lookup table instead of manually describing every case?

Yes although there are some IMM where we only need AC/AB/BC so think we would still want to check the IMM.

Are you concerned about compile time overhead? If not keeping the same logic for const / non-const seems simpler and less error prone.


================
Comment at: llvm/lib/Target/X86/X86InstCombineIntrinsic.cpp:591-594
+  // Currently we only handle cases that convert directly to another instruction
+  // or cases where all the ops are constant.  This is because we don't properly
+  // handle creating ternary ops in the backend, so splitting them here may
+  // cause regressions. As the backend improves, uncomment more cases.
----------------
pengfei wrote:
> Maybe better to do it in FE and remove all these intrinsics finally?
What do you mean? Like in the header for `_mm_ternarylogic_....` add a switch statement? Or something else?

But would prefer to keep it somewhere we have const/non-const info on A/B/C because it will currently cause regressions to simplify many of the cases (working on a patch for backend generation, but a ways away).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D145220/new/

https://reviews.llvm.org/D145220