[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) {
if(some_condition){
free(x);
exit(0);
}
}
--
Marc Glisse
More information about the llvm-commits
mailing list