[PATCH] A new HeapToStack allocation promotion pass

Marc Glisse marc.glisse at inria.fr
Fri Oct 4 06:25:49 PDT 2013

On Fri, 4 Oct 2013, Hal Finkel wrote:

> My understanding is that the extra control-flow from exception handling 
> should be accounted for by the basic-block successor/predecessor 
> information (because calling a function that might throw uses invoke, 
> and then you see both the regular predecessor and the cleanup block as 
> predecessors). I'll double-check that's correct.

Good. I was confused that you showed an example where the optimization 
cannot apply (or only with -fno-exceptions) ;-)

>> Also, you're right, I should check the
>> function's does-not-return attribute also.
> To be slightly more specific on this last point, there is some pass that 
> inserts 'unreachable' after such functions, but I should make sure that 
> we always run after it (or deal with it internally).

I don't think that works. Unreachable means the function never returns. 
What matters here is whether the function always returns (or may sometimes 
not return). I would be ok with assuming whatever we need to make this 
optimization legal, but we need to document what is forbidden:

void bar(int *x) {

Marc Glisse

More information about the llvm-commits mailing list