[Clang] Clang vs. GCC Frame Pointer Differences

[guoxin049]

We used Clang 15 to build our kernel and encountered a problem during the process. I'm not sure if this is a bug or an issue with our configuration.

• The kernel code is as follows:
  https://github.com/torvalds/linux/blob/2c85ebc57b3e1817b6ce1a6b703928e113a90442/arch/arm/kernel/unwind.c#L68-L77

enum regs {
#ifdef CONFIG_THUMB2_KERNEL
	FP = 7,
#else
	FP = 11,
#endif
	SP = 13,
	LR = 14,
	PC = 15
};

When using CONFIG_THUMB2_KERNEL, the frame pointer (FP) is set to r7. However, after compiling with Clang 15 and setting the option '-mframe-chain=aapcs+leaf', the frame pointer changes to r11.

• I noticed that this part of the llvm code caused
  

  llvm-project/llvm/lib/Target/ARM/ARMSubtarget.h

  Lines 374 to 379 in cb30169

  	MCPhysReg getFramePointerReg() const {
  	if (isTargetDarwin() ||
  	(!isTargetWindows() && isThumb() && !createAAPCSFrameChain()))
  	return ARM::R7;
  	return ARM::R11;
  	}

When the -mframe-chain=aapcs+leaf option is set, the createAAPCSFrameChain() function returns true, and the getFramePointerReg() function uses ARM::R11 as the frame pointer. However, when I compile with GCC using the options -mthumb -mabi=aapcs, it still uses r7 as the frame pointer.

• This is my demo to illustrate the difference:
  https://godbolt.org/z/GcMGhKvq1

[llvmbot]

@llvm/issue-subscribers-backend-arm

Author: gxlayer (guoxin049)

We used Clang 15 to build our kernel and encountered a problem during the process. I'm not sure if this is a bug or an issue with our configuration.

• The kernel code is as follows:
  https://github.com/torvalds/linux/blob/2c85ebc57b3e1817b6ce1a6b703928e113a90442/arch/arm/kernel/unwind.c#L68-L77

enum regs {
#ifdef CONFIG_THUMB2_KERNEL
	FP = 7,
#else
	FP = 11,
#endif
	SP = 13,
	LR = 14,
	PC = 15
};

When using CONFIG_THUMB2_KERNEL, the frame pointer (FP) is set to r7. However, after compiling with Clang 15 and setting the option '-mframe-chain=aapcs+leaf', the frame pointer changes to r11.

• I noticed that this part of the llvm code caused
  

  llvm-project/llvm/lib/Target/ARM/ARMSubtarget.h

  Lines 374 to 379 in cb30169

  	MCPhysReg getFramePointerReg() const {
  	if (isTargetDarwin() ||
  	(!isTargetWindows() && isThumb() && !createAAPCSFrameChain()))
  	return ARM::R7;
  	return ARM::R11;
  	}

When the -mframe-chain=aapcs+leaf option is set, the createAAPCSFrameChain() function returns true, and the getFramePointerReg() function uses ARM::R11 as the frame pointer. However, when I compile with GCC using the options -mthumb -mabi=aapcs, it still uses r7 as the frame pointer.

• This is my demo to illustrate the difference:
  https://godbolt.org/z/GcMGhKvq1

[efriedma-quic]

-mframe-chain=aapcs+leaf means that all functions should using an AAPCS frame pointer... and the spec in question says the frame pointer register is r11. If you really want frame pointers in r7 for some reason, -mframe-chain=none -fno-omit-frame-pointer does that, I think.

I have no idea whether gcc has equivalent options.

[guoxin049]

-mframe-chain=aapcs+leaf means that all functions should using an AAPCS frame pointer... and the spec in question says the frame pointer register is r11. If you really want frame pointers in r7 for some reason, -mframe-chain=none -fno-omit-frame-pointer does that, I think.

I have no idea whether gcc has equivalent options.

Thank you for your reply. I would like to know whether the frame pointer (FP) uses r11 or r7 when both -mframe-chain=aapcs+leaf and -mthumb options are used together. Could you clarify which register is selected for the frame pointer in this case? Thank you.

[efriedma-quic]

-mframe-chain=aapcs+leaf forces the frame pointer to r11 even in Thumb mode.

[guoxin049]

@efriedma-quic

llvm-project/llvm/lib/Target/ARM/ARMFrameLowering.cpp

Lines 2265 to 2273 in d4f6ad5

	void ARMFrameLowering::determineCalleeSaves(MachineFunction &MF,
	BitVector &SavedRegs,
	RegScavenger *RS) const {
	TargetFrameLowering::determineCalleeSaves(MF, SavedRegs, RS);
	// This tells PEI to spill the FP as if it is any other callee-save register
	// to take advantage the eliminateFrameIndex machinery. This also ensures it
	// is spilled in the order specified by getCalleeSavedRegs() to make it easier
	// to combine multiple loads / stores.
	bool CanEliminateFrame = !(requiresAAPCSFrameRecord(MF) && hasFP(MF));

Thank you for your reply. But I'm running into a problem.
I’m trying to understand the rationale behind the condition !(requiresAAPCSFrameRecord(MF) && hasFP(MF)) for setting the boolean CanEliminateFrame. Specifically, why do both conditions need to be true simultaneously?

Given that hasFP(MF) being true implies that requiresAAPCSFrameRecord(MF) would be redundant, can this logic be simplified to just bool CanEliminateFrame = !hasFP(MF)?

[efriedma-quic]

I think what happened there is that the patch that added the line (https://reviews.llvm.org/D125094; CC @pratlucas) was mostly concerned about the behavior with -mframe-chain=aapcs. So the behavior changed for that case, but not for the non-AAPCS frame chain case.

As a practical matter, it's very unlikely to make a significant difference: functions without a stack frame are generally tiny anyways.

[guoxin049]

I think what happened there is that the patch that added the line (https://reviews.llvm.org/D125094; CC @pratlucas) was mostly concerned about the behavior with -mframe-chain=aapcs. So the behavior changed for that case, but not for the non-AAPCS frame chain case.

As a practical matter, it's very unlikely to make a significant difference: functions without a stack frame are generally tiny anyways.

Thank you for your reply. Does LLVM currently generate stack pointers for smaller leaf functions, or are they optimized out in certain cases? Has the community considered the possibility of always generating stack pointers for such functions? thank you

This is my demo to illustrate clang and gcc the difference:
https://godbolt.org/z/Kf1e3crMc

[dongjianqiang2]

I think what happened there is that the patch that added the line (https://reviews.llvm.org/D125094; CC @pratlucas) was mostly concerned about the behavior with -mframe-chain=aapcs. So the behavior changed for that case, but not for the non-AAPCS frame chain case.

As a practical matter, it's very unlikely to make a significant difference: functions without a stack frame are generally tiny anyways.

I think the problem @guoxin049 found is that using the -fno-omit-frame-pointer option does not generate fp for leaf functions (Dopra uses fp to backtrace), so the option -mframe-chain=aapcs+leaf is used. However, the -mframe-chain=aapcs+leaf option is changed from r7 to r11 in thumb mode, then the kernel has compatibility issues. May I ask if you have any suggestions?

[efriedma-quic]

-mno-omit-leaf-frame-pointer should be the option to do that, but it looks like that doesn't currently work on 32-bit Arm. Which I guess is a bug.