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

[Reid Kleckner via Phabricator via llvm-commits]

rnk added a comment.

In D74651#1998063 <https://reviews.llvm.org/D74651#1998063>, @efriedma wrote:

> Your proposed solution to finding the correct type of an allocation with a corresponding call seems fine.
>
> Not sure about rewrite llvm.call.preallocated.arg to an alloca.  Not sure you'd actually want to explicitly rewrite it; probably simpler to come up with some fake stack layout and go through the normal lowering.


Based on what I know of the codegen design, that is feasible, but it will be discovered post-isel, which is pretty late. During instruction finalizations, the DenseMap entry for the call site will be missing. We can make a stack object of appropriate size and alignment at that point, but it's much less convenient than assuming we've taken care of it by CGP.

We already have to write an IR transform utility to rewrite these intrinsics to allocas, at the very least for the inliner. Functionattrs (or the new Attributor) should remove this preallocated attributes when possible, so that pass will want this utility. And, if a call site gets eliminated because it is unreachable, we'll want to call this utility from standard cleanup passes like instcombine. Once we have the utility, we might as well just call it from CGP and rely on it later, instead of implementing it a second time.

> On a related note, I just realized there isn't any discussion of alignment in the documentation.  Have you thought about how the alignment of preallocated arguments is specified?

The alignment can be surprising. For example, MSVC does not align `double` arguments or argument structs containing double, despite `alignof(double) == 8`. MSVC will align vectors and structs that carry `__declspec(align)` or `alignas` attributes, but in those cases, it passes the argument by address using a regular alloca.

Is it possible to put an `align` attribute on a return value? If so, we could put it on the return value at the call site. However, for our purposes, it would always be 4. That's never enough to do any interesting transforms, so it's almost as good as leaving it unspecified.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74651