[PATCH] D13529: [Polly] Allow alloca instructions in the SCoP
Michael Kruse via llvm-commits
llvm-commits at lists.llvm.org
Tue Feb 16 01:17:07 PST 2016
Meinersbur added a comment.
> 2. Allocas in ramdon location. We can discuss this case form the perspective of correctness and efficiency. For correctness, I assume that allocas in any location can be hoist to the entry of the function without changing the behavior the function (exclude causing a stack overflow ... we assume the stack is infinite here), otherwise, it is the function source code itself who has the problem (e.g. accessing uninitialized memory). Hence moving allocas to the entry of the function (including from the entry of an inlined callee to the entry of the caller) is a correct transformation. (Maybe recursive function call will break this assumption, and make it incorrect to move alloca to the entry of the function?)
This is not correct, even for non-recursive functions. First, the size may depend on an induction variable or something computed in the loop. Second, this would collapse multiple allocations into one, creating aliasing where none has been before (The %alloca of a previous loop iteration might still be available through a phi or storing it into a temporary location such as the oggenc.c example)
http://reviews.llvm.org/D13529
More information about the llvm-commits
mailing list