[PATCH] D55506: [RFC v2] Allow target to handle STRICT floating-point nodes

Mon Dec 10 04:33:07 PST 2018

uweigand created this revision.
uweigand added reviewers: hfinkel, cameron.mcinally, andrew.w.kaylor, kpn, arsenm, craig.topper, spatel, bogner.
Herald added subscribers: llvm-commits, wdng, qcolombet, MatzeB.

This is an alternate approach to the RFC in D45576 <https://reviews.llvm.org/D45576> / D52785 <https://reviews.llvm.org/D52785> / D52786 <https://reviews.llvm.org/D52786>.  The main difference is that we're no longer attempting to use MachineMemOperand structures to capture floating-point exception status.

Instead, we make the MI codegen explicitly aware of the floating-point exceptions by introducing two new concepts:

- A new MCID flag "mayRaiseException" that the target should set on any instruction that possibly can raise FP exception according to the architecture definition.
- A new MI flag FPExcept that CodeGen/SelectionDAG will set on any MI instruction resulting from expansion of any constrained FP intrinsic.

Any MI instruction that is *both* marked as mayRaiseException *and* FPExcept then needs to be considered as raising exceptions by MI-level codegen (e.g. scheduling).   Right now, this is done by simply treating and such instruction as if it had hasUnmodeledSideEffects set.  In a future update, we can improve on this by handling such instructions in a more tailored way in the scheduler.

Now, setting those two new flags is relatively straightforward.  The mayRaiseException flag is simply set via TableGen by marking all relevant instruction patterns in the .td files.

The FPExcept flag is set in SDNodeFlags when creating the STRICT_ nodes in the SelectionDAG, and gets inherited in the MachineSDNode nodes created from it during instruction selection.  The flag is then transfered to an MIFlag when creating the MI from the MachineSDNode.  This is handled just like fast-math flags like no-nans are handled today.  In a way, we can think of the FPExcept flag like an inverted fast-math flag "no-except" that just defaults to true instead of false.

This should address the concerns that MachineMemOperands might get dropped accidentally.  The new mayRaiseException flag is an invariant setting anyway, and the FPExcept flag is a MIFlag, and to my understanding those cannot be dropped during MI codegen anyway.

Repository:
  rL LLVM

https://reviews.llvm.org/D55506

Files:
  include/llvm/CodeGen/MachineInstr.h
  include/llvm/CodeGen/SelectionDAGNodes.h
  include/llvm/MC/MCInstrDesc.h
  include/llvm/Target/Target.td
  include/llvm/Target/TargetSelectionDAG.td
  lib/CodeGen/MIRParser/MILexer.cpp
  lib/CodeGen/MIRParser/MILexer.h
  lib/CodeGen/MIRParser/MIParser.cpp
  lib/CodeGen/MIRPrinter.cpp
  lib/CodeGen/MachineInstr.cpp
  lib/CodeGen/SelectionDAG/InstrEmitter.cpp
  lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
  lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
  lib/CodeGen/TargetLoweringBase.cpp
  lib/Target/SystemZ/SystemZISelLowering.cpp
  lib/Target/SystemZ/SystemZInstrDFP.td
  lib/Target/SystemZ/SystemZInstrFP.td
  lib/Target/SystemZ/SystemZInstrVector.td
  lib/Target/SystemZ/SystemZOperators.td
  lib/Target/SystemZ/SystemZRegisterInfo.cpp
  lib/Target/SystemZ/SystemZRegisterInfo.td
  test/CodeGen/SystemZ/RAbasic-invalid-LR-update.mir
  test/CodeGen/SystemZ/clear-liverange-spillreg.mir
  test/CodeGen/SystemZ/fp-cmp-07.mir
  test/CodeGen/SystemZ/fp-conv-17.mir
  test/CodeGen/SystemZ/fp-strict-add-01.ll
  test/CodeGen/SystemZ/fp-strict-add-02.ll
  test/CodeGen/SystemZ/fp-strict-add-03.ll
  test/CodeGen/SystemZ/fp-strict-add-04.ll
  test/CodeGen/SystemZ/fp-strict-alias.ll
  test/CodeGen/SystemZ/fp-strict-div-01.ll
  test/CodeGen/SystemZ/fp-strict-div-02.ll
  test/CodeGen/SystemZ/fp-strict-div-03.ll
  test/CodeGen/SystemZ/fp-strict-div-04.ll
  test/CodeGen/SystemZ/fp-strict-mul-01.ll
  test/CodeGen/SystemZ/fp-strict-mul-02.ll
  test/CodeGen/SystemZ/fp-strict-mul-03.ll
  test/CodeGen/SystemZ/fp-strict-mul-04.ll
  test/CodeGen/SystemZ/fp-strict-mul-05.ll
  test/CodeGen/SystemZ/fp-strict-mul-06.ll
  test/CodeGen/SystemZ/fp-strict-mul-07.ll
  test/CodeGen/SystemZ/fp-strict-mul-08.ll
  test/CodeGen/SystemZ/fp-strict-mul-09.ll
  test/CodeGen/SystemZ/fp-strict-mul-10.ll
  test/CodeGen/SystemZ/fp-strict-mul-11.ll
  test/CodeGen/SystemZ/fp-strict-round-01.ll
  test/CodeGen/SystemZ/fp-strict-round-02.ll
  test/CodeGen/SystemZ/fp-strict-round-03.ll
  test/CodeGen/SystemZ/fp-strict-sqrt-01.ll
  test/CodeGen/SystemZ/fp-strict-sqrt-02.ll
  test/CodeGen/SystemZ/fp-strict-sqrt-03.ll
  test/CodeGen/SystemZ/fp-strict-sqrt-04.ll
  test/CodeGen/SystemZ/fp-strict-sub-01.ll
  test/CodeGen/SystemZ/fp-strict-sub-02.ll
  test/CodeGen/SystemZ/fp-strict-sub-03.ll
  test/CodeGen/SystemZ/fp-strict-sub-04.ll
  test/CodeGen/SystemZ/vec-strict-add-01.ll
  test/CodeGen/SystemZ/vec-strict-add-02.ll
  test/CodeGen/SystemZ/vec-strict-div-01.ll
  test/CodeGen/SystemZ/vec-strict-div-02.ll
  test/CodeGen/SystemZ/vec-strict-max-01.ll
  test/CodeGen/SystemZ/vec-strict-min-01.ll
  test/CodeGen/SystemZ/vec-strict-mul-01.ll
  test/CodeGen/SystemZ/vec-strict-mul-02.ll
  test/CodeGen/SystemZ/vec-strict-mul-03.ll
  test/CodeGen/SystemZ/vec-strict-mul-04.ll
  test/CodeGen/SystemZ/vec-strict-mul-05.ll
  test/CodeGen/SystemZ/vec-strict-round-01.ll
  test/CodeGen/SystemZ/vec-strict-round-02.ll
  test/CodeGen/SystemZ/vec-strict-sqrt-01.ll
  test/CodeGen/SystemZ/vec-strict-sqrt-02.ll
  test/CodeGen/SystemZ/vec-strict-sub-01.ll
  test/CodeGen/SystemZ/vec-strict-sub-02.ll
  utils/TableGen/CodeGenInstruction.cpp
  utils/TableGen/CodeGenInstruction.h
  utils/TableGen/InstrInfoEmitter.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D55506.177482.patch
Type: text/x-patch
Size: 283023 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20181210/8d611c1f/attachment-0001.bin>