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.
RegisterBank Info: @LLChris talked about hand crafted code and how writing a tablegen emitter could clean this up. Thus, a NFC AArch64 patch could replace the hand crafted code. I think this must be corresponding RFC: [RFC] TableGen support for RegisterBankInfo
TSVC2 vectorisation outliers: @sjoerdmeijer talked about tickets raised with test cases for which we are behind gcc a lot. @kbeyls suggested reviewing the labels, @banach-space a dashboard. About loop-versioning and creating loops with unit strides, @davemgreen mentioned that loopaccessanalysis or the vectoriser might be able to do that.
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:
