This is an archive of the discontinued LLVM Phabricator instance.

[SDAG] Add `getCALLSEQ_END` overload taking `uint64_t`s
ClosedPublic

Authored by barannikov88 on Aug 6 2022, 10:19 AM.

Details

Summary

All in-tree targets pass pointer-sized ConstantSDNodes to the
method. This overload reduced amount of boilerplate code a bit.
This also makes getCALLSEQ_END consistent with getCALLSEQ_START,
which already takes uint64_ts.

Diff Detail

Event Timeline

barannikov88 created this revision.Aug 6 2022, 10:19 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 6 2022, 10:19 AM
barannikov88 requested review of this revision.Aug 6 2022, 10:19 AM
barannikov88 added inline comments.
llvm/include/llvm/CodeGen/SelectionDAG.h
955

This method has become unused (except for in the overload below), but I'm hesitant to remove it.
On one hand, removing it will force out-of-tree targets to adapt the new overload, on the other it should not be hard.
These nodes already require their operands to be constants, only the value type may vary, but it does not look like a problem -- this may only require a slight modification of patterns.

barannikov88 retitled this revision from [SDAG] Add `getCALLSEQ_END` overload taking `uint64_t`s to [SDAG] Add `getCALLSEQ_END` overload taking `uint64_t`s (NFC).Aug 6 2022, 10:33 AM
barannikov88 retitled this revision from [SDAG] Add `getCALLSEQ_END` overload taking `uint64_t`s (NFC) to [SDAG] Add `getCALLSEQ_END` overload taking `uint64_t`s.

Add NFC to the commit message

rusyaev-roman accepted this revision.Aug 7 2022, 9:03 AM
rusyaev-roman added a subscriber: rusyaev-roman.

lgtm

llvm/include/llvm/CodeGen/SelectionDAG.h
955

From my point of view it's better to preserve this function to provide additional customization in the future.

This revision is now accepted and ready to land.Aug 7 2022, 9:03 AM

@craig.topper @spatel @MaskRay
Could you please merge it? I don't have permission.

jrtc27 added inline comments.Aug 9 2022, 1:29 PM
llvm/include/llvm/CodeGen/SelectionDAG.h
967

Size1/Size2 aren't great names; getCALLSEQ_START calls them InSize and OutSize which seems better to me.

barannikov88 added inline comments.Aug 9 2022, 1:50 PM
llvm/include/llvm/CodeGen/SelectionDAG.h
967

The meaning of these values is target-dependent (see the comment near CALLSEQ_START/CALLSEQ_END nodes). Giving them any specific names would suggest the opposite. "InSize" and "OutSize" are not very meaningful names anyway (what is "in" and "out" here?).

jrtc27 added inline comments.Aug 9 2022, 2:36 PM
llvm/include/llvm/CodeGen/SelectionDAG.h
967

That full comment is:

/// CALLSEQ_START/CALLSEQ_END - These operators mark the beginning and end
/// of a call sequence, and carry arbitrary information that target might
/// want to know.  The first operand is a chain, the rest are specified by
/// the target and not touched by the DAG optimizers.
/// Targets that may use stack to pass call arguments define additional
/// operands:
/// - size of the call frame part that must be set up within the
///   CALLSEQ_START..CALLSEQ_END pair,
/// - part of the call frame prepared prior to CALLSEQ_START.
/// Both these parameters must be constants, their sum is the total call
/// frame size.
/// CALLSEQ_START..CALLSEQ_END pairs may not be nested.

CALLSEQ_START and CALLSEQ_END are identical in this regard, so having the mismatch in naming between getCALLSEQ_START and getCALLSEQ_END is odd to me. Note that on architectures that don't use the stack for arguments (like NVPTX) these aren't even sizes; NVPTX just uses an incrementing counter that exists solely to end up in assembly comments AFAICT.

barannikov88 added inline comments.Aug 9 2022, 3:30 PM
llvm/include/llvm/CodeGen/SelectionDAG.h
967

CALLSEQ_START and CALLSEQ_END are identical in this regard

It seems so, according to the comment. In reality, however, targets give different meaning to the second argument of the CALLSEQ_END. X86, for instance, uses it to record the "callee pop" size (i.e. the adjustment made to the stack pointer by the call).
I understand your concern, I myself don't like vague names, but in this particular case I think making the names specific is making them misleading.
My last justification is that the overloaded function names these values as "Op1" and "Op2".

barannikov88 added inline comments.Aug 9 2022, 3:33 PM
llvm/include/llvm/CodeGen/SelectionDAG.h
967

Please also note that these nodes have other uses, not related to calls. See ExpandDYNAMIC_STACKALLOC, for example.

Could someone please merge this straightforward change?
Here are the details:
Sergei Barannikov <barannikov88@gmail.com>