[llc] incorrect stackmap generated for arm64

[lzheng5]

Hello,

We believe the following generated stackmap for the attached case is wrong. This only happens on arm64. x64 is correct.

Please refer to https://llvm.org/docs/StackMaps.html#stackmap-format.

    uint8  : Register | Direct | Indirect | Constant | ConstantIndex
    uint8  : Reserved (expected to be 0)
    uint16 : Location Size
    uint16 : Dwarf RegNum
    uint16 : Reserved (expected to be 0)
    int32  : Offset or SmallConstant

[bad]

Ltmp9-_next_criticals967_code7BCE

        .byte	3 # Indirect
	.byte	0 
	.short	8
	.short	19 # RegNum (wrong)
	.short	0
	.long	56 # Offset (wrong)

[good]

Ltmp9-_next_criticals967_code7BCE

        .byte	3 # Indirect
	.byte	0 
	.short	8
	.short	29 # RegNum (correct)
	.short	0
	.long	-56 # Offset (correct)

r29 should the frame register on arm64. And the offset should be negative.

llc --version
LLVM (http://llvm.org/):
  LLVM version 17.0.2
  Optimized build.
  Default target: arm64-apple-darwin23.6.0
  Host CPU: apple-m1

Thanks,
Ling

[lzheng5]

case.txt
bad.txt
good.txt

[lzheng5]

One related question:

  uint64 : Function Address
  uint64 : Stack Size (or UINT64_MAX if not statically known)
  uint64 : Record Count

	.quad	_next_criticals967_code7BCE
	.quad	-1 # Stack Size
	.quad	33

I wonder why in this case on both arm64 and x64 I got -1 for the stack size? Even though I have many statepoints and a few more alloca instructions.

Thanks,
Ling

[efriedma-quic]

In cases where a function has both overaligned variables and dynamic allocation, LLVM keeps three pointers to the stack: the stack pointer, the frame pointer, and the base pointer. The base pointer is x19. See https://github.com/llvm/llvm-project/blob/43b6b78771e9ab4da912b574664e713758c43110/llvm/lib/Target/AArch64/AArch64FrameLowering.cpp .

Given that, I don't see anything wrong here; your proposed "fix" actually corrupts the stackmap.

[lzheng5]

Thanks for the reply!

Yes. After a second look at the generated arm64 assembly, I did notice that it sometimes uses x19 with a positive offset and sometimes x29 with a negative offset.

Based on the diagram shown on line 36 in AArch64FrameLowering.cpp,

high address
fp
bp
sp 
low address

My intention is to convert the addresses (given by reg + offset) of the spilled value relative to the stack pointer. Then I can directly access the spilled values just using the current sp.

For x64, I assume LLVM only keeps the stack pointer and the frame pointer? In that case, I believe we can convert the offset relative to rbp to an offset relative to rsp by adding the frame size (it is -1 for my case however).

It is unclear to me why I have this over alignment issue if you check the 3 alloca alignment in next_criticals967_code7BCE. They should all be word-size aligned. And I didn't do dynamic allocation either.

For arm64, I believe the reason why we get the x19 is because of the following unknown area. So if we can solve above issue, then we should be able to have a work around.

// |-----------------------------------|
// |.empty.space.to.make.part.below....|
// |.aligned.in.case.it.needs.more.than| (size of this area is unknown at
// |.the.standard.16-byte.alignment....|  compile time; if present)
// |-----------------------------------|

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

Author: Ling (lzheng5)

Hello,

We believe the following generated stackmap for the attached case is wrong. This only happens on arm64. x64 is correct.

Please refer to https://llvm.org/docs/StackMaps.html#stackmap-format.

    uint8  : Register | Direct | Indirect | Constant | ConstantIndex
    uint8  : Reserved (expected to be 0)
    uint16 : Location Size
    uint16 : Dwarf RegNum
    uint16 : Reserved (expected to be 0)
    int32  : Offset or SmallConstant

[bad]

Ltmp9-_next_criticals967_code7BCE

        .byte	3 # Indirect
	.byte	0 
	.short	8
	.short	19 # RegNum (wrong)
	.short	0
	.long	56 # Offset (wrong)

[good]

Ltmp9-_next_criticals967_code7BCE

        .byte	3 # Indirect
	.byte	0 
	.short	8
	.short	29 # RegNum (correct)
	.short	0
	.long	-56 # Offset (correct)

r29 should the frame register on arm64. And the offset should be negative.

llc --version
LLVM (http://llvm.org/):
  LLVM version 17.0.2
  Optimized build.
  Default target: arm64-apple-darwin23.6.0
  Host CPU: apple-m1

Thanks,
Ling

[efriedma-quic]

The function has dynamic allocation: one of the allocas is not in the entry block.

See

llvm-project/llvm/lib/Target/AArch64/AArch64RegisterInfo.cpp

Line 602 in 92a15dd

bool AArch64RegisterInfo::hasBasePointer(const MachineFunction &MF) const {

for the exact conditions that trigger a base pointer.

[lzheng5]

Thanks for the clarification!

Once I have manually lifted the alloca()s in my generated code, I can see that fp/bp won't be needed.

Initially, I thought LLVM should do the lifting automatically when giving an IR src.