[PATCH] D30671: [GlobalISel] Translate floating-point negation

Kristof Beyls via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 7 01:14:32 PST 2017


kristof.beyls added inline comments.


================
Comment at: lib/CodeGen/GlobalISel/IRTranslator.cpp:174-185
+bool IRTranslator::translateFSub(const User &U, MachineIRBuilder &MIRBuilder) {
+  // -0.0 - X --> G_FNEG
+  if (isa<Constant>(U.getOperand(0)) &&
+      U.getOperand(0) == ConstantFP::getZeroValueForNegation(U.getType())) {
+    MIRBuilder.buildInstr(TargetOpcode::G_FNEG)
+        .addDef(getOrCreateVReg(U))
+        .addUse(getOrCreateVReg(*U.getOperand(1)));
----------------
Hi Volkan,

It's unclear to me why we really need a G_FNEG generic opcode.
If the idea is to later on be able to generate a target-specific FNEG instruction, why not have a pattern that can map G_FSUB 0.0, X to a targets specific FNEG, e.g.FNEGDr  for AArch64, during the InstructionSelect phase?
Or would the existing DAGISel patterns that contain fneg grow horribly complex if we don't have G_FNEG?

Unless there is a good reason for having an explicit G_FNEG opcode, it seems to me it's best to keep the number of generic opcodes as small as possible?

Thanks,

Kristof


https://reviews.llvm.org/D30671





More information about the llvm-commits mailing list