[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