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

Volkan Keles via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 7 01:26:46 PST 2017


volkan 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)));
----------------
kristof.beyls wrote:
> 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
Hi Kristof,

Sorry for the lack of explanation. We need to have G_FNEG in order to lower G_FSUB in Legalizer as it may not be legal for some targets.

Thanks,
Volkan


https://reviews.llvm.org/D30671





More information about the llvm-commits mailing list