[PATCH] D137497: [ArgumentPromotion] Allow the frontend to specify the maximum number of elements to promote on a per-function basis via metadata.

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri added a comment.

Can't the heuristics be improved instead?
Offloading this decision to (each) front-end seems rather sub-optimal.

In D137497#3910548 <https://reviews.llvm.org/D137497#3910548>, @pcwalton wrote:

> As an alternative, I wonder if we could teach SROA to do a form of argument promotion for nocapture noalias readonly dereferenceable aligned arguments. If the only thing blocking an alloca from SROA is being passed into a function by nocapture noalias readonly dereferenceable aligned pointer, insert a new alloca and memcpy to "reform" the structure right before the call, change the call to pass a pointer to the new alloca containing the "reformed" structure, and then the original alloca becomes SROAable. This could avoid all those ugly spills and reloads in the `drop_in_place` function bodies... assuming we could come up with some kind of heuristic to know when it's worth inserting copies to perform SROA in these instances.

FWIW, that is rather exactly what i'm doing in https://reviews.llvm.org/D113520. It seems to work, but is needs some legality check, because it can end up trying to promote backing alloca, over and over again.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137497