This is an archive of the discontinued LLVM Phabricator instance.

[AArch64][Statepoints] Statepoint support for AArch64.
ClosedPublic

Authored by loicottet on Aug 9 2019, 7:19 AM.

Details

Summary

Provides support for garbage collection statepoints in the AArch64 backend. The GC transition flag is not supported yet.

Diff Detail

Event Timeline

loicottet created this revision.Aug 9 2019, 7:19 AM
loicottet updated this revision to Diff 214790.Aug 13 2019, 2:53 AM

Correction of failing test cases

phosek added a subscriber: phosek.Aug 19 2019, 1:57 PM
loicottet retitled this revision from Statepoint support for AArch64 to [AArch64][Statepoints] Statepoint support for AArch64.Aug 21 2019, 7:13 AM
loicottet retitled this revision from [AArch64][Statepoints] Statepoint support for AArch64 to [AArch64][Statepoints] Statepoint support for AArch64..
loicottet updated this revision to Diff 216835.Aug 23 2019, 7:02 AM

Style changes

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–820

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.
If this is a bug in the target-independent part of statepoint support, I think it'd be best to split this off as a separate patch, with a regression tests demonstrating this issue on a target that already supports statepoints (which I presume is only x86_64 today).

llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
445–448

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?

sanjoy edited reviewers, added: apilipenko; removed: sanjoy.Sep 18 2019, 1:44 PM
sanjoy added a subscriber: sanjoy.Sep 18 2019, 1:51 PM

I don't work on statepoints anymore.

reames requested changes to this revision.Oct 20 2019, 6:28 PM
reames added inline comments.
llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp
816–820

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
445–448

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.

779

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)

This revision now requires changes to proceed.Oct 20 2019, 6:28 PM
loicottet marked 3 inline comments as done.Nov 8 2019, 7:11 AM
loicottet added inline comments.
llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp
816–820

This has indeed nothing to do here. I removed it.

llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
445–448

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.

779

Reverted. I misunderstood the patching behaviours of the intrinsics.

llvm/lib/Target/AArch64/AArch64FrameLowering.cpp
2227–2241

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
185–188

Not sure about this, I'd appreciate if someone could confirm this is the way to do it.

loicottet updated this revision to Diff 228447.Nov 8 2019, 7:13 AM

Addressed comments

loicottet marked an inline comment as done.Nov 11 2019, 1:49 AM
loicottet added inline comments.
llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
445–448

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.

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.

ostannard accepted this revision.Sep 8 2020, 2:31 AM
ostannard added a subscriber: ostannard.

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
456

Comment should be updated.

llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp
185–188

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
6

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
9

naive

reames accepted this revision.EditedSep 14 2020, 2:28 PM

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.

This revision is now accepted and ready to land.Sep 14 2020, 2:28 PM
This revision was automatically updated to reflect the committed changes.

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.