[PATCH] D11815: Pass subtarget feature "force-align-stack"

[Akira Hatanaka via cfe-commits]

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