Referencing alloca'd memory in tail calls is invalid IR. This was
not caught by the verifier, but produced misoptimizations due to
wrong alias analysis results.
is found to see if it can actually happen instead of just assuming it will.
This allows it to catch cases like
{{{
int i;
Foo f;
while (cond(i))
f = new Foo(i++);
return f.value;
}}}
where it previously wouldn't because a phi using the allocation would appear in
the condition block to propagate it to the use after the loop.
allocations too. (A "simple" loop is one where the allocation isn't used in a
subsequent iteration)
This also means it's no longer necessary to run this pass multiple times.
Running it once after inlining should now catch all cases.
(b) don't override the delete operator (on top of the regular conditions for
stack allocation that also apply to arrays, structs, etc.).
The "no destructor" clause is not strictly necessary, but calling them at the
right time would be tricky to say the least; it would involve, among other
things, "manually" inserting a try-finally block around anything that might
throw exceptions not caught in the current function.
Note: objects with custom new operators are automatically ignored because they
don't use the regular allocation runtime call, so there's no need to pay special
attention to them.
This one promotes GC allocations to stack memory when it can determine it's safe
to do so.
Not all GC calls are recognized yet (in fact only one *is* recognized for now).
Needs metadata, so disabled for LLVM versions that don't support it.
