[PATCH] A new HeapToStack allocation promotion pass

[Chandler Carruth]

On Mon, Oct 7, 2013 at 8:31 AM, Hal Finkel <hfinkel at anl.gov> wrote:

> If the value is captured, then I need to make sure that there are no
> blocking (synchronizing) calls along the execution path. This includes
> analyzing the function containing the malloc/free. I could just reject
> captured malloc values, but, unless I'm going to reject any execution path
> with any function call, then I need to know if the functions will return
> normally (regardless of whether or not the malloc is captured). And since I
> need to know if the functions on the execution path return normally anyway,
> I might as well look for the problematic loops (and atomic/volatile
> accesses) while I'm at it.
>

I really, *really* think that a function attribute that is propagated up
the call graph is the only scalable and effective way to implement this. I
think doing it in your pass is the wrong design.


>
> I could certainly start with a version that just rejects all function
> calls, but it is not clear to me that the rest of it is particularly
> complicated; and I would not be satisfied with such a solution: it would
> miss a bunch of low-hanging fruit.
>

As discussed with you in person, I think that this is essentially going to
be a prototype anyways, and will need to be modified significantly (both in
design and implementation) before being enabled. So I think a conservative
version is fine, and I wouldn't even bother enabling it by default. The
goal of committing an early version is not to start catching some missed
optimization opportunities but to make subsequent development incremental
and easier to review.

I still really do not think we have the right design here specifically as
regards interactions with SROA. I think that's OK because we can fix that
incrementally.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131007/3d8167ed/attachment.html>