vkalintiris added a comment. In http://reviews.llvm.org/D11815#237541, @ahatanak wrote:
> In http://reviews.llvm.org/D11815#236368, @vkalintiris wrote: > > > In http://reviews.llvm.org/D11815#235394, @ahatanak wrote: > > > > > > > > > > > > > For example, on a Mips target, where the O32 ABI requires either way an > > 8-byte alignment, we would generate redundant code for realigning the stack > > to a 4-byte alignment if a function contains objects with maximum alignment > > of 4-bytes (see attached files to get an idea). > > > I wonder if there is a target or a use case that requires or prefers > realigning the stack to an alignment that is smaller than the default stack > alignment. If there is no such target or use case, I think we can just using > the existing attribute StackAlignment (with value 0) rather than adding a new > function attribute "stackrealign", which will ensure the stack is at least > aligned to the default value and force realigning the stack. I was thinking something similar. I'm not quite sure but the only case I can think of, where we might get away with an alignment smaller than the default, is when we emit code for the fast calling convention. Other than that, I believe that we should duplicate the functionality of X86FrameLowering::calculateMaxStackAlign() (or override it in each target accordingly). > The purpose of this patch is to make sure -mstackrealign works when doing LTO Out of curiosity, I was wondering why dynamic stack realignment isn't enough for LTO. I would guess that the alignment of the data types used under SSE might have a smaller alignment than the one required by the ABI. http://reviews.llvm.org/D11815 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
