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

Bill Wendling via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 8 15:55:04 PST 2022


void added a comment.

In D92695#2435333 <https://reviews.llvm.org/D92695#2435333>, @majnemer wrote:

> It is difficult remembering exactly what my thought process was way back when but the redzone calculation seems very likely...
>
> Lets see...
>
> 011980cd50d5ddc5112c8440ffe9161de60b40ae was where I first implemented these intrinsics.
>
> Looking at the Win64 ABI, there is this bit <https://docs.microsoft.com/en-us/cpp/build/stack-usage?view=msvc-160#function-types:~:text=A%20leaf%20function%20is%20one%20that,to%20any%20nonvolatile%20registers%2C%20including%20RSP>:
>
>> A leaf function is one that does not require a function table entry. It can't make changes to any nonvolatile registers, including RSP, which means that it can't call any functions or allocate stack space.
>
> Using these intrinsics must not violate this rule of the ABI so I forced frame pointers across all platforms.

That definition implies that `pushf`/`popf` can't be used in leaf functions, because they implicitly modify the stack pointer.

  $ cat eflags.c
  #include <stdio.h>
  
  int main()
  {
  	unsigned long x;
  	asm volatile ("movq %%rsp, %0\n\t"
  		      : "=r"(x));
  	printf("RSP: 0x%016x\n", x);
  	asm volatile ("pushf\n\t"
  		      "movq %%rsp, %0\n\t"
  		      : "=r"(x));
  	printf("RSP: 0x%016x\n", x);
  	return 0;
  }
  $ gcc eflags.c && ./a.out
  RSP: 0x00000000c4cae7a0
  RSP: 0x00000000c4cae798



> The Linux ABI for x86-64 says that there are 128-bytes reserved for leaf functions. IIRC, forcing a frame pointer here also handled some complicated accounting issue of when or how much redzone we had to play with because this intrinsic allocates some stack...
>
> +1 to @craig.topper's comments.




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