[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