Provides support for garbage collection statepoints in the AArch64 backend. The GC transition flag is not supported yet.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I'm afraid I'm not up to speed on statepoints, but I thought I'd give some feedback nonetheless on the code as is.
I hope it's useful.
llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp | ||
---|---|---|
816–819 ↗ | (On Diff #216835) | It seems strange to me that adding AArch64-target specific support (the purpose of this patch, I presume) needs a generic target-independent change like this. |
llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp | ||
541–545 | If I understand the semantics of this change, the goal is to emit stack maps not only for MachO targets, but for all targets, such as those using ELF or COFF. |
llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp | ||
---|---|---|
816–819 ↗ | (On Diff #216835) | This does not look correct to me. I'd definitely demand to see a separate patch with a clear test case justifying this. |
llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp | ||
541–545 | I agree on the separable patch bit. I think this is pretty straight forward, but a simple test and one line patch would be good. | |
892 | This is wrong. STACKMAP and PATCHPOINT are destructive patching. STATEPOINT assumes non-destuctive patching. (i.e. no shadow region, nops explicitly supported and likely replaced before the code ever runs) |
llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp | ||
---|---|---|
816–819 ↗ | (On Diff #216835) | This has indeed nothing to do here. I removed it. |
llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp | ||
541–545 | I've been able to use statepoint and stackmap intrinsics and emit stack maps using these changes without trouble (for ELF at least). From the git history, it appears that the stack map was originally emitted for all object file formats until the MachO hack was added in be1d1b66. It looks like the stack map emission was included in it by mistake. I'll open a separate patch to fix this. | |
892 | Reverted. I misunderstood the patching behaviours of the intrinsics. | |
llvm/lib/Target/AArch64/AArch64FrameLowering.cpp | ||
2227–2240 ↗ | (On Diff #216835) | Should this bugfix be part of a separate patch or is it ok to leave it in this PR as it enables correct statepoint operation? |
llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp | ||
195–198 | Not sure about this, I'd appreciate if someone could confirm this is the way to do it. |
llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp | ||
---|---|---|
541–545 |
ping. I'd appreciate it if someone could take a look at the corrections I've made and tell me what this patch still needs to land. Thanks!
Just pinging this issue as a GraalVM user, this is blocking the most realistic way forward for Java for interop libraries, iOS or WASM. Gluon does not appear to use this patch for iOS and Graal 20 does not ship with it either in their in-tree LLVM fork. So maybe I'm misunderstanding how important it is. But please take another look.
The patch is now included the LLVM fork of GraalVM and will be included in the next release. AFAIK Gluon should switch to using this build as well in the near future.
Pinging this again, almost out of desperation at this point. This patch has been used in production in the GraalVM Native Image project, notably to create iOS executables through the Gluon Substrate tool (https://github.com/gluonhq/substrate) for more than a year now. I'm happy to address any remaining issue in the patch, but I'll need some feedback to do that.
I don't know too much about statepoints or GC, but you have addressed all of @reames comments, and the AArch64 parts and code style look correct to me, so LGTM.
llvm/lib/Target/AArch64/AArch64RegisterInfo.cpp | ||
---|---|---|
614 | Comment should be updated. | |
llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp | ||
195–198 | This looks right to me, none of the first 5 arguments need to be materialised as actual runtime values, so marking them as free is correct. | |
llvm/test/CodeGen/AArch64/fast-isel-gc-intrinsics.ll | ||
5 ↗ | (On Diff #228447) | This test is only checking for crashes, is there anything in here which wouldn't be caught by the other tests? |
llvm/test/CodeGen/AArch64/statepoint-stack-usage.ll | ||
8 ↗ | (On Diff #228447) | naive |
LGTM as well.
The change doesn't apply cleanly at the moment, and normally I'd request the author update it before LGTMing, but given how long this has been outstanding I'm just going to do the rebase myself, tweak comments slightly in one spot, and land.
When rebasing, I discovered the tests for this were from before the operand bundle format change. Given that, I ended up dropping most of the tests. I'll land a couple more in a follow up, but overall, it seems reasonable to have most testing in the x86 target. We don't need to exercise all cornercases in both places.
If I understand the semantics of this change, the goal is to emit stack maps not only for MachO targets, but for all targets, such as those using ELF or COFF.
This implies that stack maps are not supported for ELF AArch64. According to documentation at https://llvm.org/docs/StackMaps.html stackmaps are also needed for supporting stackmap and patchpoint intrinsics.
In the spirit of incremental development, I wonder if it'd be possible to again split this off as a separate patch, introducing stackmap support?
I guess to do that, also support for patchpoint and stackmap intrinsics for ELF (and COFF?) targeting AArch64 may be needed, which may be non-trivial? OTOH, it seems those are already supported for MachO AArch64, so maybe it'd be a relatively small/simple thing to do in a separate patch?
Do you intend to also support COFF, or only add support for ELF here? If so, the emitStackMaps may still need to be guarded by an if-condition?