[llvm-dev] [RFC] Replacing inalloca with llvm.call.setup and preallocated

[Eli Friedman via llvm-dev]

From: Arthur Eubanks <aeubanks at google.com>
Sent: Monday, July 6, 2020 11:56 AM
To: Eli Friedman <efriedma at quicinc.com>
Cc: Reid Kleckner <rnk at google.com>; llvm-dev <llvm-dev at lists.llvm.org>
Subject: [EXT] Re: [llvm-dev] [RFC] Replacing inalloca with llvm.call.setup and preallocated



On Thu, Jun 25, 2020 at 2:15 PM Eli Friedman <efriedma at quicinc.com<mailto:efriedma at quicinc.com>> wrote:
The llvm.call.preallocated.teardown, then, is only necessary if we manage to throw an exception before we reach the call with the preallocated bundle.  (For example, if the constructor for a function argument throws an exception.)
Does it make sense to say that in order to avoid stack leaks, exactly one of either the preallocated call or the teardown must be called? And if both are called it's UB?

Yes, exactly.

The one part that’s a little tricky is I’m not sure how llvm.call.preallocated.teardown is supposed to work on the exceptional path.  If you try to take stack memory allocated outside a funclet, and free it inside a funclet, we can’t actually free the memory at the point of the call, so there isn’t any simple lowering.
I assume you mean the exceptional path of e.g. a previous constructor, not the preallocated call. I don't understand how it would be any different from a typical stackrestore of an inalloca in a funclet.

I don’t think inalloca actually works correctly here.  So comparing it isn’t really helpful.

-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200707/7abaabe1/attachment.html>