This is a reminder that tomorrow the 14th of November there’s a AArch64 Sync-up call at 4PM GMT / 8AM PST.
We have a call every month to coordinate between contributors aiming to improve or enable AArch64 code-generation.
- SME update
- Performance: TSVC2 vectorisation outliers (e.g. #71511, #71512, #71515, #71517, #71519, etc.)
- Please share any topics in this thread
Google Meet: https://meet.google.com/hqk-runc-agf
Attendees are required to adhere to the LLVM Code of Conduct (LLVM Community Code of Conduct — LLVM 18.0.0git documentation). For any Code of Conduct reports, please contact the organizers, and also email firstname.lastname@example.org.
Hi, I’m working on a patch for RegisterBankEmitter and I’m going to join the sync-up call tomorrow. I’m also talking with @qcolombet and @topperc.
RegisterBankEmitter currently doesn’t write out PartialMappings, PartialMappingIdx and BankIDToCopyMapIdx. Instead these tables+enums are hand crafted by the backends. Handling this is pretty easy for 7 of the 9 GlobalISel backends, RISCV and AArch64 are exceptions.
In AArch64, this stuff is kept in AArch64GenRegisterBankInfo.def and AArch64RegisterBankInfo.h. You also have Cross register bank copies in ValMapping which I don’t think can be generated from the TableGen .td files. PowerPC mentions cross register bank copies but doesn’t actually have the ValMapping data for it. It does have something odd in ValMapping for CCR. I’m going to talk to the PowerPC people next week. Anyways, I’ll argue for putting that in a separate table or describe it in TableGen and I’ll extend the emitter for it.
Otherwise, this should be a simple patch: generate what the backends are already hand crafting. Ideally, this is all one big fat NFC. You can also just ignore the TableGen’d code and nothing will break.
Hi, I submitted target independent proposal for consistent branches and AArch64 support ( FEAT_HBC ) [RFC] Consistent branches support in LLVM. It would be great to get feedback on it and ideas where compiler should generate them. Off the top of my head it would be beneficial for runtime detection mechanisms like out-of-line atomics and Function Multi Versioning.
Here are my minimal notes, which are incomplete catching only the high level messages. Feel free to add and correct anything!
Thanks for organizing @sjoerdmeijer !
I think that it’s best if I refer to (which is basically what I tried to summarise):
There’s two things I forgot to add.
If I recall well, @ktkachov-arm suggested we could also use the meeting to talk about patches (in case there are no other topics) if people would like to bring that up.
I have also added the next meetings to the LLVM calendar:
- December 12th 2023 @ 4pm BST / 8am PST
- January 9th 2024 @ 4pm BST / 8am PST
- February 6th 2024 @ 4pm BST / 8am PST
- March 5th 2024 @ 4pm BST / 8am PST
- April 9th 2024 @ 4pm BST / 8am PST