[PATCH] D86393: [GISel] Add combines for unary FP instrs with constant operand
Jessica Paquette via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Sep 4 14:08:41 PDT 2020
paquette added inline comments.
================
Comment at: llvm/include/llvm/Target/GlobalISel/Combine.td:294
+// Fold fneg(cst) to cst result of fneg operation
+def constant_fneg_matchinfo: GIDefMatchData<"Optional<APFloat>">;
----------------
Is there any reason these are all separate combines, when they're all using the same function? Have you found it useful to be able to turn these on/off per-opcode?
Most other combines look like this:
```
def fconstant_matchinfo: GIDefMatchData<"Optional<APFloat>">;
def constant_fold_unary: GICombineRule <
(defs root:$root, fconstant_matchinfo:$info),
(match (wip_match_opcode G_FNEG, G_FABS, G_FPTRUNC, G_FSQRT, G_FLOG2):$root,
[{ return Helper.matchCombineConstantFoldFpUnary(*${root}, ${info}); }]),
(apply [{ return Helper.applyCombineConstantFoldFpUnary(*${root}, ${info}); }])
>;
```
================
Comment at: llvm/include/llvm/Target/GlobalISel/Combine.td:295
+// Fold fneg(cst) to cst result of fneg operation
+def constant_fneg_matchinfo: GIDefMatchData<"Optional<APFloat>">;
+def constant_fneg: GICombineRule <
----------------
Do you need separate `matchinfo` definitions?
I've noticed all the combines do this, but I think it would be better to just say
```
def fconstant_matchinfo: GIDefMatchData<"Optional<APFloat>">;
```
and then reuse it in every combine that uses it versus redefining matchinfo for every combine. (The rest of the combines could probably be cleaned up similarly in a later commit if this works)
================
Comment at: llvm/lib/CodeGen/GlobalISel/CombinerHelper.cpp:1449
+ default:
+ return None;
+ case TargetOpcode::G_FNEG: {
----------------
This should probably assert or be a `llvm_unreachable`, since we never expect to run this with any other opcode.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D86393/new/
https://reviews.llvm.org/D86393
More information about the llvm-commits
mailing list