[RFC] TableGen-erate SDNode descriptions #119709

s-barannikov · 2024-12-12T14:25:35Z

Landed changes:
#138381 RISCV
#138450 Sparc
#138869 XCore
#138874 ARC, CSKY, Lanai
#138878 MSP430
#139407 AVR
#139449 M68k
#140472 AArch64
#166253 Xtensa
#166259 WebAssembly
#166499 BPF
#168108 PowerPC
#168113 SystemZ
#168120 VE
#168129 LoongArch
#168212 ARM
#168248 AMDGPU
#168367 NVPTX

topperc · 2024-12-12T16:55:37Z

llvm/include/llvm/CodeGen/SelectionDAGNodes.h

-  /// Test if this node has a target-specific
-  /// memory-referencing opcode (in the \<target\>ISD namespace and
-  /// greater than FIRST_TARGET_MEMORY_OPCODE).
-  bool isTargetMemoryOpcode() const {


Do we still need isTargetMemoryOpcode(). It doesn't have any callers.

It has one use in the assert in SelectionDAG::getMemIntrinsicNode.

Oops. I was looking in my local repo and should have checked for FIRST_TARGET_MEMORY_OPCODE to see that assert

If nothing else is checking it, does that assert provide any value? Can we just allow any target opcode to be a memory opcode?

I remembered it has one more "use". Before this patch it is implicitly checked here. isTargetStrictFPOpcode returns true for memory opcodes as well. mayRaiseFPException is then used here to decide whether the resulting MachineInstr needs NoFPExcept flag. IIUC it will not set this flag on MachineInstrs if the matched SDNode(s) were flagged as memory accessing (or having strict-fp semantics).

This behavior was introduced in 6333679. I couldn't conclude if it is safe to return false for memory opcodes so I left it as is.

After this patch the check is explicit, please see SelectionDAGTargetInfo.cpp:mayRaiseFPException.

I ran CodeGen tests with the memory opcode check disabled and there was one failure in
X86/fp-intrinsics-flags.ll. The following diff resolves it:

There was a discussion in https://reviews.llvm.org/D72466 that can be related to this. Can you confirm that this is a safe change? If so, then quoting @uweigand from https://reviews.llvm.org/D71841 I assume the check for memory opcode can be dropped:

Note that there a bit of a quirk in identifying target nodes that are both memory nodes and strict FP nodes. To simplify the logic, right now all target memory nodes are automatically also considered strict FP nodes -- this could be fixed by adding one more range.

A future patch adds a couple of new methods to this class, which will need to be overridden by these targets. Part of llvm#119709.

…argets (#119968) #119969 adds a couple of new methods to this class, which will need to be overridden by these targets. Part of #119709. Pull Request: #119968

…de (#119969) With this change, targets are no longer required to put memory / strict-fp opcodes after special `ISD::FIRST_TARGET_MEMORY_OPCODE`/`ISD::FIRST_TARGET_STRICTFP_OPCODE` markers. This will also allow autogenerating `isTargetMemoryOpcode`/`isTargetStrictFPOpcode (#119709). Pull Request: #119969

This patch adds a simplistic backend that gathers all target-specific SelectionDAG nodes and emits descriptions for most of them. This includes generating node enumeration, node names, and information about node "prototype" that can be used to verify that a node is valid. The patch also extends SDNode by adding target-specific flags, which are also included in the generated tables. Part of llvm#119709, [RFC](https://discourse.llvm.org/t/rfc-tablegen-erating-sdnode-descriptions/83627).

This patch adds a simplistic backend that gathers all target-specific SelectionDAG nodes and emits descriptions for most of them. This includes generating node enumeration, node names, and information about node "prototype" that can be used to verify that a node is valid. The patch also extends SDNode by adding target-specific flags, which are also included in the generated tables. Part of #119709, [RFC](https://discourse.llvm.org/t/rfc-tablegen-erating-sdnode-descriptions/83627). Pull Request: #123002

This patch introduces SelectionDAGGenTargetInfo and SDNodeInfo classes, which provide methods for accessing the generated SDNode descriptions. RFC: https://discourse.llvm.org/t/rfc-tablegen-erating-sdnode-descriptions Draft PR: llvm#119709

This allows SDNodes to be validated against their expected type profiles and reduces the number of changes required to add a new node. There is only one node that is missing a description -- `GET_CCMASK`, others were successfully imported. Part of #119709. Pull Request: #168113

github-actions · 2025-11-17T22:27:50Z

🐧 Linux x64 Test Results

186423 tests passed
4867 tests skipped

This allows SDNodes to be validated against their expected type profiles and reduces the number of changes required to add a new node. The validation functionality has detected several issues, see `PPCSelectionDAGInfo::verifyTargetNode()`. Most of the nodes have a description in `*.td` files and were successfully "imported". Those that don't have a description are listed in the enum in `PPCSelectionDAGInfo.td`. These nodes are not validated. Part of #119709. Pull Request: #168108

This allows SDNodes to be validated against their expected type profiles and reduces the number of changes required to add a new node. Some nodes fail validation, those are enumerated in `ARMSelectionDAGInfo::verifyTargetNode()`. Some of the bugs are easy to fix, but probably they should be fixed separately, this patch is already big. Part of #119709. Pull Request: #168212

This allows SDNodes to be validated against their expected type profiles and reduces the number of changes required to add a new node. The verification functionality detected a few issues, two of them were fixed (missing `SDNPMemOperand` property on `TCGEN05_MMA` nodes and extra glue operand/result on `CallPrototype`), the one remaining is with `ProxyReg` node, see `NVPTXSelectionDAGInfo::verifyTargetNode()`. Part of #119709. Pull Request: #168367

This allows SDNodes to be validated against their expected type profiles and reduces the number of changes required to add a new node. I had to split `VSHUF4I` into two variants (`VSHUF4I` and `VSHUF4I_D`) since `loongarch_vshuf4i` and `loongarch_vshuf4i_d` have different number of operands, and this prevented the node from being imported. There is just one node that currently fails validation, see `LoongArchSelectionDAGInfo::verifyTargetNode()`. Part of #119709. Pull Request: #168129

This allows SDNodes to be validated against their expected type profiles and reduces the number of changes required to add a new node. Autogenerated node names start with "AMDGPUISD::", hence the changes in the tests. The few nodes defined in R600.td are *not* imported because TableGen processes AMDGPU.td that doesn't include R600.td. Ideally, we would have two sets of nodes, but that would require careful reorganization of td files since some nodes are shared between AMDGPU/R600. Not sure if it something worth looking into. Some nodes fail validation, those are listed in `AMDGPUSelectionDAGInfo::verifyTargetNode()`. Part of llvm#119709. Pull Request: llvm#168248

This allows SDNodes to be validated against their expected type profiles and reduces the number of changes required to add a new node. There is only one node that is missing a description -- `GET_CCMASK`, others were successfully imported. Part of llvm#119709. Pull Request: llvm#168113

This allows SDNodes to be validated against their expected type profiles and reduces the number of changes required to add a new node. The validation functionality has detected several issues, see `PPCSelectionDAGInfo::verifyTargetNode()`. Most of the nodes have a description in `*.td` files and were successfully "imported". Those that don't have a description are listed in the enum in `PPCSelectionDAGInfo.td`. These nodes are not validated. Part of llvm#119709. Pull Request: llvm#168108

This allows SDNodes to be validated against their expected type profiles and reduces the number of changes required to add a new node. Some nodes fail validation, those are enumerated in `ARMSelectionDAGInfo::verifyTargetNode()`. Some of the bugs are easy to fix, but probably they should be fixed separately, this patch is already big. Part of llvm#119709. Pull Request: llvm#168212

This allows SDNodes to be validated against their expected type profiles and reduces the number of changes required to add a new node. The verification functionality detected a few issues, two of them were fixed (missing `SDNPMemOperand` property on `TCGEN05_MMA` nodes and extra glue operand/result on `CallPrototype`), the one remaining is with `ProxyReg` node, see `NVPTXSelectionDAGInfo::verifyTargetNode()`. Part of llvm#119709. Pull Request: llvm#168367

This allows SDNodes to be validated against their expected type profiles and reduces the number of changes required to add a new node. I had to split `VSHUF4I` into two variants (`VSHUF4I` and `VSHUF4I_D`) since `loongarch_vshuf4i` and `loongarch_vshuf4i_d` have different number of operands, and this prevented the node from being imported. There is just one node that currently fails validation, see `LoongArchSelectionDAGInfo::verifyTargetNode()`. Part of llvm#119709. Pull Request: llvm#168129

This allows SDNodes to be validated against their expected type profiles and reduces the number of changes required to add a new node. Some nodes fail validation, those are enumerated in `ARMSelectionDAGInfo::verifyTargetNode()`. Some of the bugs are easy to fix, but probably they should be fixed separately, this patch is already big. Part of llvm#119709. Pull Request: llvm#168212

This allows SDNodes to be validated against their expected type profiles and reduces the number of changes required to add a new node. The verification functionality detected a few issues, two of them were fixed (missing `SDNPMemOperand` property on `TCGEN05_MMA` nodes and extra glue operand/result on `CallPrototype`), the one remaining is with `ProxyReg` node, see `NVPTXSelectionDAGInfo::verifyTargetNode()`. Part of llvm#119709. Pull Request: llvm#168367

This allows SDNodes to be validated against their expected type profiles and reduces the number of changes required to add a new node. I had to split `VSHUF4I` into two variants (`VSHUF4I` and `VSHUF4I_D`) since `loongarch_vshuf4i` and `loongarch_vshuf4i_d` have different number of operands, and this prevented the node from being imported. There is just one node that currently fails validation, see `LoongArchSelectionDAGInfo::verifyTargetNode()`. Part of llvm#119709. Pull Request: llvm#168129

This allows SDNodes to be validated against their expected type profiles and reduces the number of changes required to add a new node. Many DSP nodes were failing validation, this is fixed as part of this PR. Part of #119709. Pull Request: #168307

This allows SDNodes to be validated against their expected type profiles and reduces the number of changes required to add a new node. Many DSP nodes were failing validation, this is fixed as part of this PR. Part of llvm#119709. Pull Request: llvm#168307

This comment was marked as off-topic.

Sign in to view

llvm deleted a comment from github-actions bot Dec 12, 2024

s-barannikov force-pushed the tablegen/sdnode-info-emitter branch from 2a57488 to b90b16f Compare December 12, 2024 16:44

This comment was marked as off-topic.

Sign in to view

topperc reviewed Dec 12, 2024

View reviewed changes

s-barannikov marked this pull request as ready for review December 13, 2024 13:37

s-barannikov force-pushed the tablegen/sdnode-info-emitter branch from b90b16f to ad38786 Compare December 14, 2024 12:34

This was referenced Dec 14, 2024

[SelectionDAG] Add empty implementation of SelectionDAGInfo to some targets #119968

Merged

[SelectionDAG] Virtualize isTargetStrictFPOpcode / isTargetMemoryOpcode #119969

Merged

s-barannikov force-pushed the tablegen/sdnode-info-emitter branch from ad38786 to 7ed14ef Compare December 16, 2024 20:32

s-barannikov force-pushed the tablegen/sdnode-info-emitter branch 3 times, most recently from 7dd3721 to c315879 Compare December 21, 2024 15:10

s-barannikov force-pushed the tablegen/sdnode-info-emitter branch 2 times, most recently from 5d1058f to 3ba779a Compare January 14, 2025 18:44

s-barannikov mentioned this pull request Jan 15, 2025

[TableGen] Add a backend generating SDNode descriptions #123002

Merged

s-barannikov mentioned this pull request Jan 21, 2025

[X86] Add verifyTargetSDNode for x86 target specific nodes #123589

Draft

s-barannikov force-pushed the tablegen/sdnode-info-emitter branch from 3ba779a to 4c7893b Compare January 22, 2025 06:20

s-barannikov force-pushed the tablegen/sdnode-info-emitter branch from 4c7893b to ae89705 Compare February 1, 2025 19:08

s-barannikov mentioned this pull request Feb 1, 2025

[SelectionDAG] Wire up -gen-sdnode-info TableGen backend #125358

Merged

This was referenced Nov 17, 2025

[Mips] TableGen-erate SDNode descriptions #168307

Merged

[NVPTX] TableGen-erate SDNode descriptions #168367

Merged

[X86] TableGen-erate SDNode descriptions #168421

Open

s-barannikov force-pushed the tablegen/sdnode-info-emitter branch from f425081 to 38d2191 Compare November 17, 2025 21:41

s-barannikov force-pushed the tablegen/sdnode-info-emitter branch from 38d2191 to 5fd7c92 Compare November 18, 2025 00:23

s-barannikov force-pushed the tablegen/sdnode-info-emitter branch from 5fd7c92 to eba3dc9 Compare November 18, 2025 18:45

s-barannikov force-pushed the tablegen/sdnode-info-emitter branch from eba3dc9 to 38ecac7 Compare November 18, 2025 23:49

s-barannikov added 4 commits November 20, 2025 18:33

Hexagon

5398dac

Mips

005825b

X86

37f4838

Generic bugs

d8dbcb0

s-barannikov force-pushed the tablegen/sdnode-info-emitter branch from 38ecac7 to d8dbcb0 Compare November 20, 2025 15:33

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[RFC] TableGen-erate SDNode descriptions #119709

[RFC] TableGen-erate SDNode descriptions #119709

Uh oh!

s-barannikov commented Dec 12, 2024 •

edited

Loading

Uh oh!

This comment was marked as off-topic.

This comment was marked as off-topic.

topperc Dec 12, 2024

Uh oh!

s-barannikov Dec 12, 2024

Uh oh!

topperc Dec 12, 2024

Uh oh!

topperc Dec 12, 2024

Uh oh!

s-barannikov Dec 12, 2024 •

edited

Loading

Uh oh!

s-barannikov Dec 12, 2024

Uh oh!

github-actions bot commented Nov 17, 2025 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

[RFC] TableGen-erate SDNode descriptions #119709

Are you sure you want to change the base?

[RFC] TableGen-erate SDNode descriptions #119709

Uh oh!

Conversation

s-barannikov commented Dec 12, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as off-topic.

This comment was marked as off-topic.

topperc Dec 12, 2024

Choose a reason for hiding this comment

Uh oh!

s-barannikov Dec 12, 2024

Choose a reason for hiding this comment

Uh oh!

topperc Dec 12, 2024

Choose a reason for hiding this comment

Uh oh!

topperc Dec 12, 2024

Choose a reason for hiding this comment

Uh oh!

s-barannikov Dec 12, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

s-barannikov Dec 12, 2024

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Nov 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🐧 Linux x64 Test Results

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

s-barannikov commented Dec 12, 2024 •

edited

Loading

s-barannikov Dec 12, 2024 •

edited

Loading

github-actions bot commented Nov 17, 2025 •

edited

Loading