Details
Diff Detail
Event Timeline
lib/CodeGen/GlobalISel/IRTranslator.cpp | ||
---|---|---|
174–185 | Hi Volkan, It's unclear to me why we really need a G_FNEG generic opcode. 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 |
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, |
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. 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? |
lib/CodeGen/GlobalISel/IRTranslator.cpp | ||
---|---|---|
174–185 |
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
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