[PATCH] D131329: [SDAG] Add `getCALLSEQ_END` overload taking `uint64_t`s

[Jessica Clarke via Phabricator via llvm-commits]

jrtc27 added inline comments.


================
Comment at: llvm/include/llvm/CodeGen/SelectionDAG.h:967
 
+  SDValue getCALLSEQ_END(SDValue Chain, uint64_t Size1, uint64_t Size2,
+                         SDValue Glue, const SDLoc &DL) {
----------------
barannikov88 wrote:
> jrtc27 wrote:
> > Size1/Size2 aren't great names; getCALLSEQ_START calls them InSize and OutSize which seems better to me.
> 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?).
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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131329/new/

https://reviews.llvm.org/D131329