[PATCH] D74651: Add IR constructs for inalloca replacement llvm.call.setup

Reid Kleckner via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Apr 16 10:02:06 PDT 2020


rnk added a comment.

In D74651#1985561 <https://reviews.llvm.org/D74651#1985561>, @aeubanks wrote:

> In D74651#1985474 <https://reviews.llvm.org/D74651#1985474>, @rnk wrote:
>
> > Arthur, now that you've worked with the names a bit, do you feel like they make sense? Would you change them?
>
>
> `@llvm.call.alloc` is weird because it's not allocating anything, the allocation happens in `@llvm.call.setup`. Maybe `@llvm.call.arg` is better?


I think when I came up with this terminology, I was thinking that `alloc` would actually do the allocation, so there would be a staircase of ESP adjustments. However, it's true, in the current implementation, `alloc` is a misnomer, and we might never implement SP staircasing (I don't have a better name for this code pattern...).

Consider the code MSVC generates for a call like this:
https://gcc.godbolt.org/z/TeLRRa

  struct Foo { Foo(int x); Foo(const Foo &o); ~Foo(); int x, y; };
  void callee(int, Foo, int, Foo, int, Foo);
  void bar() {
    callee(1, Foo(2), 3, Foo(4), 5, Foo(6));
  }

Each ESP adjustment happens immediately before the argument is evaluated. It lets the compiler pass scalar memory arguments with the PUSH instruction, which is good for code size, and I hear performance, although I have no first hand evidence of this.

---

In any case, I think we should use a name that makes sense for either implementation strategy.

Should we double down on the `preallocated` terminology? `llvm.call.preallocated.arg`? The number arguments make more sense this way, they refer to the N'th "preallocated" argument. The pattern would be:

  %cs = call token @llvm.call.setup(i32 3)
  %x = call i8* @llvm.call.preallocated.arg(token %cs, i32 0)
  %y = call i8* @llvm.call.preallocated.arg(token %cs, i32 1)
  %z = call i8* @llvm.call.preallocated.arg(token %cs, i32 2)
  ...

(I suppose that if we ever wanted to do staircasing, we would have to require that the calls be evaluated right to left.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74651





More information about the llvm-commits mailing list