[PATCH] D14147: Hanlding of aligned allocas on a target that does not align stack pointer.

[Ulrich Weigand via llvm-commits]

uweigand added a comment.

In http://reviews.llvm.org/D14147#294457, @hfinkel wrote:

>




> > but also results in more efficient code for targets like SystemZ, since we do not require to reserve an extra hard register

> 

> 

> This seems untrue. Even if you don't reserve a register for the base pointer, by handling these as dynamic allocations, you force yourself to keep separate pointers to each overaligned stack allocation. In short, you trade one reserved register for N virtual ones (one for each over-aligned stack object). It is true that you might spill those virtual registers when they're not needed, but that's a current-infrastructure problem not a theoretical one, and even so, unlikely to be a win.


Just to clarify: my "more efficient" comment refered to the way this feature is implemented in GCC today, where  common code already groups all overaligned variables into a "secondary stack frame" and uses only a single alloca to allocate this frame and only a single virtual register to access it.   I certainly agree that the (initial) LLVM implementation in Jonas' patch is not generally more efficient, but has the drawbacks you mention.  I still think Jonas' patch is a good first step:

- It actually implements overaligned variables correctly for all platforms without requiring target-specific code.
- It can always be improved upon in the future to be more like the GCC implementation described above.
- It should already be more efficient for the -likely common- case of functions using just one single overaligned variable.

> In general, over-aligned objects are a performance feature, and should be implemented in a high-performance way. The question here seems to be: Do we want to have a suboptimal, but still functionally correct, support for over-aligned stack objects? I think having this capability makes sense, so long as it comes with appropriate comments and explanations in the code about the downsides. Let's proceed.


Agreed that we should have comments explaining the downsides of the current implementation and suggestions for future improvements.

Thanks for the review!


http://reviews.llvm.org/D14147