This is an archive of the discontinued LLVM Phabricator instance.

[GlobalISel] Translate floating-point negation
ClosedPublic

Authored by volkan on Mar 6 2017, 4:23 PM.

Diff Detail

Event Timeline

volkan created this revision.Mar 6 2017, 4:23 PM
kristof.beyls added inline comments.Mar 7 2017, 1:14 AM
lib/CodeGen/GlobalISel/IRTranslator.cpp
174–185

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

volkan added inline comments.Mar 7 2017, 1:26 AM
lib/CodeGen/GlobalISel/IRTranslator.cpp
174–185

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

kristof.beyls added inline comments.Mar 7 2017, 3:03 AM
lib/CodeGen/GlobalISel/IRTranslator.cpp
174–185

Thanks, that makes me understand the rationale a lot better - I wasn't aware of targets with this constraint.

I'm still wondering though if in legalization for such a target, it means that G_FSUB should have a custom legalization that somehow doesn't depend on a generic G_FNEG opcode being present? It's not that I'm very against adding G_FNEG when there's a good rationale for it; but I'm wondering if we wouldn't end up with a messy set of generic opcodes if we need to add more and more specialized generic opcodes for all possible out-of-tree targets with non-traditional constraints.
I honestly don't know the best way forward. I'm hoping that @qcolombet may have a better view on this than myself?

Other than that, on this patch, my guess is that this will break existing in-tree targets that already support GlobalISel G_FSUB, like AArch64. So if we go ahead with adding G_FNEG, maybe this patch should also add the necessary support for the in-tree targets that already handle G_FSUB to also handle G_FNEG?

qcolombet accepted this revision.Mar 7 2017, 9:59 AM

Thanks for the confirmation.

Makes sense to me.

This revision is now accepted and ready to land.Mar 7 2017, 9:59 AM
volkan closed this revision.Mar 7 2017, 10:15 AM
ab added inline comments.Mar 7 2017, 10:25 AM
lib/CodeGen/GlobalISel/IRTranslator.cpp
174–185

Other than that, on this patch, my guess is that this will break existing in-tree targets that already support GlobalISel G_FSUB, like AArch64. So if we go ahead with adding G_FNEG, maybe this patch should also add the necessary support for the in-tree targets that already handle G_FSUB to also handle G_FNEG?

I share Kristof's concern. Doesn't this break AArch64? Should G_FNEG be legalized to G_FSUB?

Forgot to point out that you would need to add legalizer support for FNEG => FSUB 0.0, X