[PATCH] D92695: [X86ISelLowering] don't emit frame pointers for eflags intrinsics.

Craig Topper via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Dec 4 15:31:21 PST 2020


craig.topper added a comment.

In D92695#2435063 <https://reviews.llvm.org/D92695#2435063>, @nickdesaulniers wrote:

> In D92695#2435025 <https://reviews.llvm.org/D92695#2435025>, @craig.topper wrote:
>
>> Maybe the linux kernel disables the red zone and this isn't a problem.
>
> The x86_64 (64b) Linux kernel is built with `-mno-red-zone`; I'm not sure if that's precisely the same as "disables the red zone."

Yes that's what I meant.

>> But I worry about others using these builtins without disabling the red zone.
>
> Wouldn't `-fno-omit-frame-pointer` or `/Oy-` as described in this commit message prevent that?  This patch is mostly about matching GCCs behavior for these builtins, so "others using these builtins without disabling the red zone" would already be broken in such a case when built with GCC.

Yes -fno-omit-frame-pointer would fix it. gcc seems to handle the redzone correctly when readeflags is present. Compare the two functions here, https://godbolt.org/z/j7hdYY. With the readeflags builtin, there is a stack pointer adjustment near the beginning. In the second function there is no stack pointer adjustment. Adding -mno-red-zone will put a stack adjustment in the second function.

So I think this patch breaks a case that works with clang and gcc today. I don't think requiring -fno-omit-frame-pointer to use the builtins with clang is a good solution.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92695/new/

https://reviews.llvm.org/D92695



More information about the llvm-commits mailing list