[PATCH] D13529: [Polly] Allow alloca instructions in the SCoP

Johannes Doerfert via llvm-commits llvm-commits at lists.llvm.org
Thu Oct 8 03:11:04 PDT 2015


jdoerfert added a comment.

In http://reviews.llvm.org/D13529#262273, @Meinersbur wrote:

> alloca is most definitely not like any other instruction. When placed in a loop, the stack will grow in every iteration an eventually lead to a stack overflow. Such code is more than evil. How did you even manage to make Clang output such code? It should also have added stacksave/stackrestore intrinsics.
>
> The question is, whether it matters for Polly. How does it handle the situation that %B refers to different memory in every iteration? Are there infinitely many arrays in the scop, since there are infinitely many base addresses? Are base addresses that are variant within the scop even valid?
>
> Since the semantics of allocas in loops are dangerous and there is probably no valid use for them without stackrestore, I strongly recommend against this.


@deadalnix.

> Pretty much, there is a lot of problem that arise when you put alloca in random places.




> I am also surprised 'alloc' is not different to any other instruction.




> We can possibly support it in some way, but this requires some additional thoughts similar to what Michael suggested. Will the varying base pointer cause troubles, .../. Can you dead-code-eliminate allocs? Can you reorder allocs?




> Do you actually have a use case that produces such kind of code and that makes it worth to support this case? As deadalnix pointed out, allocas outside of the entry block have a lot of surprising behaviors (and are e.g. not even considered by mem2reg for good reasons).



http://reviews.llvm.org/D13529





More information about the llvm-commits mailing list