[PATCH] D90046: [LiveDebugValues] Handle spill locations with a fixed and scalable component.

[Jeremy Morse via Phabricator via llvm-commits]

jmorse added a comment.

Ah, I hadn't quite lined up in my head that the offset scales as the stack grows downwards. With that in mind, I think this sounds safe -- the scalable part of the stack offset is opaque as far as LiveDebugValues is concerned, and we can just pass it around.

Are there any scenarios where stack slots can be accessed with different scalable offsets? For example if stack slot colouring merged two slots for vectors of different scalable size (maybe it doesn't do that). If that happened, the StackOffset object would compare differently, and we might miss a spilt value being overwritten (see llvm/test/DebugInfo/MIR/X86/live-debug-values-stack-clobber.mir for a scalar example of overwrites).

The size of a VarLoc object increases from 72 bytes to ~80 bytes on amd64; this isn't ideal, but trying to micro-optimise it at this stage invites errors.



================
Comment at: llvm/test/CodeGen/AArch64/live-debugvalues-sve.mir:148-150
+    ADJCALLSTACKUP 0, 0, implicit-def dead $sp, implicit $sp, debug-location !34
+    renamable $z2 = COPY $z0, debug-location !34
+    B %bb.3, debug-location !35
----------------
I'd recommend also testing restoring the vector to a register, to ensure LiveDebugValues chops the spill-expression off correctly. VarLocBasedLDV should put in a DBG_VALUE after loading from the stack; you should need to clobber the stack location with some other value to force InstrRefBasedLDV to issue another DBG_VALUE.


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

https://reviews.llvm.org/D90046