ahatanak added a comment. In http://reviews.llvm.org/D11815#236368, @vkalintiris wrote:
> In http://reviews.llvm.org/D11815#235394, @ahatanak wrote: > > > The cc1 option "-mstackrealign" now means "force stack realignment" rather > > than "allow stack realignment" and causes function attribute "stackrealign" > > to be attached to the functions in the IR. > > > Please, correct me if I'm wrong but I believe that the -force-align-stack > option. which was removed in http://reviews.llvm.org/D11814, was x86-specific > (in the sense that it was only really tested in X86) and almost always > accompanied by a -stack-alignment value that was equal or greater than the > requirements of the ABI. > > With this change the -mstackrealign option will attach the "stackrealign" > attribute on every function definition (and declaration) without specifying a > valid -stack-alignment value. -force-align-stack used to be an x86 option but has been a target independent option since r242727 (see the discussion in http://reviews.llvm.org/D11160). The purpose of this patch is to make sure -mstackrealign works when doing LTO. It is not intended to change the way -mstackrealign is handled by clang and llvm (except that -mno-stackrealign has a different meaning now). > I suspect that this option will be broken for every Target that relies only > on the maximum alignment provided by MachineFrameInfo (see > X86FrameLowering::calculateMaxStackAlign() for the correct way to handle > this). > > Is this the intended behaviour here? I'm a little bit cautious because this > option would be exposed from the Clang frontend and our users would generate > bad code if they were to try this option. I'm not sure if this is the intended behavior, but it looks like it deviates from gcc's -mstackrealign. > 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). According to the link below, originally -mstackrealign was used to keep the stack aligned to 16-bytes when there was a possibility that the calling function's stack was only 4-byte aligned. For mips, I don't know what the right thing to do is, but its seems pointless to align the stack to 4-bytes when the default alignment is 8-byte. https://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/i386-and-x86_002d64-Options.html > F803573: main.s <http://reviews.llvm.org/F803573> > > F803574: main.c <http://reviews.llvm.org/F803574> > > F803575: main.ll <http://reviews.llvm.org/F803575> http://reviews.llvm.org/D11815 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
