-
Notifications
You must be signed in to change notification settings - Fork 15.2k
[SelectionDAG] Virtualize isTargetStrictFPOpcode / isTargetMemoryOpcode #119969
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
c51459a
00891c6
7e6a290
7f06770
d844547
45bea92
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -23,6 +23,23 @@ static cl::opt<bool> | |
| "to lower to librt functions"), | ||
| cl::init(true)); | ||
|
|
||
| bool AArch64SelectionDAGInfo::isTargetMemoryOpcode(unsigned Opcode) const { | ||
| return Opcode >= AArch64ISD::FIRST_MEMORY_OPCODE && | ||
| Opcode <= AArch64ISD::LAST_MEMORY_OPCODE; | ||
| } | ||
|
|
||
| bool AArch64SelectionDAGInfo::isTargetStrictFPOpcode(unsigned Opcode) const { | ||
| switch (static_cast<AArch64ISD::NodeType>(Opcode)) { | ||
| default: | ||
| return false; | ||
| case AArch64ISD::STRICT_FCMP: | ||
| case AArch64ISD::STRICT_FCMPE: | ||
| case AArch64ISD::SME_ZA_LDR: | ||
| case AArch64ISD::SME_ZA_STR: | ||
|
||
| return true; | ||
| } | ||
| } | ||
|
|
||
| SDValue AArch64SelectionDAGInfo::EmitMOPS(unsigned Opcode, SelectionDAG &DAG, | ||
| const SDLoc &DL, SDValue Chain, | ||
| SDValue Dst, SDValue SrcOrValue, | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you're going to start table generating the enum values for this, can you just set a high bit in the enum value for memory / strictfp?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unless I misunderstood you, it would require clearing these bits on any use of opcode, e.g. when creating a node or using the enum value as an index into the [generated] table.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, the enum values would just be larger values. For table compression you could implicitly know the chain status and truncate the table value
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see your point now. This may work well for strict-fp opcodes, but it will be more difficult to implement for memory opcodes.
Not all memory opcodes will be generated, because some targets do not provide a tablegen description for all memory nodes. This means that some enum members will have to be assigned a value by hand, and this won't look pretty.
Some target that provide tablegen descriptons for memory nodes do not set SDNPMemOperand property on them. As a result, the generated enum values will not have the "memory bit" set, and there is no way to change the enum value included from a generated file.
In the future, we may want to add more properties (e.g.,
isBinOp), which I think is by itself a good justification for adding a separate field for them rather than encoding them in the opcode.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sounds more like a bug. Your RFC sold not requiring targets to use this as a feature, but I'd consider it a defect. It would be better if targets were required to generate this kind of information from tablegen
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Depends how you look at it. It wasn't a bug before the proposed changes; targets were not required to describe all target-specific opcodes in *.td files.
Yes, otherwise it wouldn't be sold. This feature/defect allows gradual migration.
I guess we can do that once all in-tree targets have migrated. Probably need to give some time to downstream targets, too.