Reminder: the purpose is to coordinate between active contributors. If you have support questions etc then it’s best to post to LLVM’s Discourse or Discord.
We have a call every alternate Thursday at 4pm BST (4pm GMT from the next meeting onwards). If you have topics to discuss, please email me ahead of time and I can add them to the agenda.
Attendees are required to adhere to the LLVM Code of Conduct For any Code of Conduct reports, please contact me, and also email conduct@llvm.org.
Dial-in details:
We have a shared calendar that may help in keeping track, which is
accessible through:
Status of vector intrinsics and their stability (treating them as experimental?)
Potential ABI issues related to inline subword atomics emulation and setting __GCC_HAVE_SYNC_COMPARE_AND_SWAP_{1,2}. See gcc bug 104338 and 84568
AOB
Next Meeting: Thu 10th November 2022, 4pm GMT (Europe and USA will have exited daylight savings time at this point, so for most people the local time won’t change) TBD. Nov 10th is rather close to the LLVM dev meeting, and two weeks after that is thanksgiving in the US.
I don’t know if I should go over this during this kind of meeting (I unfortunately cannot attend tomorrow’s meeting) but I wanted to ask if there is any appetite for the RISC-V backend to adopt GlobalISel.
@asb Alex, do you think we should discuss at this venue or should I start a separate RFC?
Hi Quentin - I think it would be great to discuss further at a future sync-up call if you’re able to make it. As for an RFC, I think that’s largely up to your judgement at this stage. I suppose a useful thing for us to understand is how you see GlobalISel + RISC-V and the the extent to which you’re hoping to attract further help in achieving that (review time, engineering time). Fleshing out RISC-V GlobalISel support is an obviously good thing to do and I can’t see any pushback on doing that and enabling for O0 at least. But if you see limitations with the SelectionDAG approach we’re facing in the RISC-V backend that would be addressed by GlobalISel and you believe moving towards using GlobalISel by default would address them, it would probably be useful for everyone to have some discussion about it.
I had started a couple of years ago to look into doing GlobalISel support for RISC-V but haven’t had the hours spare to keep it updated and get the patches landed. If there was a good case for it though then that might be good motivation for me to pick it up again and dedicate some time to it. I thought it would be interesting to ‘try it out and see’, but nothing more concrete than that. There has also been some discussion about how long it takes to migrate a target entirely to GlobalISel, so it could be a longer task than I initially thought as well.
Anything that you can get started on GISel sounds good.
The more targets use it the more mature the framework will get!
That said, you’re right, it takes time to migrate an entire target to GISel (see what Apple is doing with Aarch64) and this definitely needs to be a concerted effort if we want to achieve it.
I’m somewhat in the same boat as you, I can help on adopting GISel (review, small patches, etc.), but I don’t have a lot of bandwidth to dedicate to it (at least right now).