[FPEnv] New document for adding new constrained FP intrinsics

[kpn]

Summary

Just like it it says on the tin: This document describes how to add a new constrained floating point intrinsics. It is intended to be a starting point for this topic.

It was split out of D55897, which itself was split out of D43515.

[andrew.w.kaylor]

docs/AddingConstrainedIntrinsics.rst

63

I don't understand this last sentence. Our strict nodes do use the chain and the non-strict versions don't, right?

BTW, Craig tells me that we're probably going to have to rethink the who mutateStrictFPToFP think to keep instruction ordering correct. I'm not suggesting that you change that in this document now. Just mentioning it as something to think about.

[cameron.mcinally]

docs/AddingConstrainedIntrinsics.rst

63

BTW, Craig tells me that we're probably going to have to rethink the who mutateStrictFPToFP think to keep instruction ordering correct. I'm not suggesting that you change that in this document now. Just mentioning it as something to think about.

Digressing a bit...

I also ran into problems with mutateStrictFPToFP and Custom lowerings in D54649.

Ideally mutateStrictFPToFP would go away once we have proper backend support. E.g. D55506. Although, I suppose it will take some time for all the backends to get up to speed, so mutateStrictFPToFP will have to live on for some time... :/

[kpn]

docs/AddingConstrainedIntrinsics.rst

63

I think I wrote that back when I was trying to avoid use of the chain. Plus, some of the code got moved to the legalizer since then. I've reworded this to be more current and reflect use of the chain.

[andrew.w.kaylor]

lgtm

docs/AddingConstrainedIntrinsics.rst

+==================================================
+How To Add A Constrained Floating-Point Intrinsic
+==================================================
+
+.. contents::
+   :local:
+
+.. warning::
+  This is a work in progress.
+
+Add the intrinsic
+=================
+
+Multiple files need to be updated when adding a new constrained intrinsic.
+
+Add the new intrinsic to the table of intrinsics.::
+
+  include/llvm/IR/Intrinsics.td
+
+Update class ConstrainedFPIntrinsic to know about the intrinsics.::
+
+  include/llvm/IR/IntrinsicInst.h
+
+Functions like ConstrainedFPIntrinsic::isUnaryOp() or
+ConstrainedFPIntrinsic::isTernaryOp() may need to know about the new
+intrinsic.::
+
+  lib/IR/IntrinsicInst.cpp
+
+Update the IR verifier::
+
+  lib/IR/Verifier.cpp
+
+Add SelectionDAG node types
+===========================
+
+Add the new STRICT version of the node type to the ISD::NodeType enum.::
+
+  include/llvm/CodeGen/ISDOpcodes.h
+
+In class SDNode update isStrictFPOpcode()::
+
+  include/llvm/CodeGen/SelectionDAGNodes.h
+
+A mapping from the STRICT SDnode type to the non-STRICT is done in
+TargetLoweringBase::getStrictFPOperationAction(). This allows STRICT
+nodes to be legalized similarly to the non-STRICT node type.::
+
+  include/llvm/CodeGen/TargetLowering.h
+
+Building the SelectionDAG
+-------------------------
+
+The switch statement in SelectionDAGBuilder::visitIntrinsicCall() needs
+to be updated to call SelectionDAGBuilder::visitConstrainedFPIntrinsic().
+That function, in turn, needs to be updated to know how to create the
+SDNode for the intrinsic. The new STRICT node will eventually be converted
+to the matching non-STRICT node. For this reason it should have the same
+operands and values as the non-STRICT version but should also use the chain.
+This makes subsequent sharing of code for STRICT and non-STRICT code paths
+easier.::
+
+  lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
+
+Most of the STRICT nodes get legalized the same as their matching non-STRICT
+counterparts. A new STRICT node with this property must get added to the
+switch in SelectionDAGLegalize::LegalizeOp().::
+
+  lib/CodeGen/SelectionDAG/LegalizeDAG.cpp
+
+Other parts of the legalizer may need to be updated as well. Look for
+places where the non-STRICT counterpart is legalized and update as needed.
+Be careful of the chain since STRICT nodes use it but their counterparts
+often don't.::
+
+The code to do the conversion or mutation of the STRICT node to a non-STRICT
+version of the node happens in SelectionDAG::mutateStrictFPToFP(). Be
+careful updating this function since some nodes have the same return type
+as their input operand, but some are different. Both of these cases must
+be properly handled.::
+
+  lib/CodeGen/SelectionDAG/SelectionDAG.cpp
+
+To make debug logs readable it is helpful to update the SelectionDAG's
+debug logger:::
+
+  lib/CodeGen/SelectionDAG/SelectionDAGDumper.cpp
+
+Add documentation and tests
+===========================
+
+::
+
+  docs/LangRef.rst

docs/index.rst

.. toctree::
    AliasAnalysis
    MemorySSA
    BitCodeFormat
    BlockFrequencyTerminology
    BranchWeightMetadata
    Bugpoint
    CodeGenerator
    ExceptionHandling
+   AddingConstrainedIntrinsics
    LinkTimeOptimization
    SegmentedStacks
    TableGenFundamentals
    TableGen/index
    DebuggingJITedCode
    GoldPlugin
    MarkedUpDisassembly
    SystemLibrary

 
 :doc:`Vectorizers`
    This document describes the current status of vectorization in LLVM.
 
 :doc:`ExceptionHandling`
    This document describes the design and implementation of exception handling
    in LLVM.
 
+:doc:`AddingConstrainedIntrinsics`
+   Gives the steps necessary when adding a new constrained math intrinsic
+   to LLVM.
+
 :doc:`Bugpoint`
    Automatic bug finder and test-case reducer description and usage
    information.
 
 :doc:`BitCodeFormat`
    This describes the file format and encoding used for LLVM "bc" files.
 
 :doc:`Support Library <SupportLibrary>`