[PATCH] D135447: [AMDGPU] Add llvm.is.fpclass intrinsic to existing SelectionDAG fp class support and introduce GlobalISel implementation for AMDGPU
Matt Arsenault via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Nov 10 19:19:22 PST 2022
arsenm added inline comments.
================
Comment at: llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp:2320
+ case Intrinsic::is_fpclass: {
+ unsigned Flags = MachineInstr::copyFlagsFromInstruction(CI);
+
----------------
JanekvO wrote:
> arsenm wrote:
> > This should get an IRTranslator test to make sure the flags are passed through
> Not sure if I completely hit the mark with my added test, but to me it seemed that not all flags were possible (e.g., `nnan` flag didn't work as it required a fp return type). For now I've added flag related tests that explicitly test the addition of `nofpexcept`. Do let me know if there's something missing or whether this `copyFlagsFromInstruction` is better omitted.
I'd consider that a pre-existing bug in intrinsics. The IR is annoyingly strict about what things are allowed to have flags
================
Comment at: llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp:2332
+ .addImm(TestMaskValue.getZExtValue())
+ .addImm((unsigned)APFloat::SemanticsToEnum(FpSem))
+ .setMIFlag(MachineInstr::NoFPExcept);
----------------
JanekvO wrote:
> arsenm wrote:
> > Do you really need the float type operand? I know bfloat16 isn't going to work without it, but I thought the plan was to introduce FP types to LLT
> I believe it's not necessary for amdgpu but required for the `G_IS_FPCLASS` target opcode. Leaving it out results in verifier errors (I also am unaware about introducing FP types and LLT).
What do you mean verifier errors?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D135447/new/
https://reviews.llvm.org/D135447
More information about the llvm-commits
mailing list