RISC-V LLVM sync-up call 30th March 2023 (note daylight savings time impact)

Code Generation RISCV
1

Note: Both the US and Europe have now entered daylight savings time, so for most attendees we should be back to the usual time (if you added the calendar, it should show the right time). We’ll be back to normal for the next meeting, when Europe enters daylight savings time too.

For background on these calls, see here.

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 GMT If you have topics to discuss, please email me ahead of time or add 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:

Agenda (copied from the linked doc - if you have additional items please add them):

2

Two more topic from me:

First one is -march for profile, which is the follow up of Define -march string by cmuellner · Pull Request #26 · riscv-non-isa/riscv-toolchain-conventions · GitHub, Christoph has proposed one solution to reduce the confusion on the toolchian-sig meeting: Use all caps of profile name only, e.g. -march=RVA22U64

And the second one is Define relocations for ULEB128 value: R_RISCV_SET_ULEB128 and R_RISCV_SUB_ULEB128 by kito-cheng · Pull Request #361 · riscv-non-isa/riscv-elf-psabi-doc · GitHub get merged, I am little worry about the toolchain incompatible between the LLVM and GNU toolchain before the newer binutils has release…

I mean the llvm will produce new relocation, it will got trouble for a while before using newer binutils, however there would be no issue IF user using lld and the problem will gone once binutils updated.

FYI: @MaskRay @jrtc27

3

Thanks Kito, I haven’t seen it proposed externally so I’ll feedback here. Maybe it will grow on me, but my first reaction is it might be a case of the cure being worse than the disease, as suddenly having to switch to all caps doesn’t seem very intuitive either. I think it’s a bit of a shame the profiles have fairly obtuse names that are easily confused with ISA naming strings (and I know I was one explicitly raising this concern), but we can support it just fine and perhaps it’s not worth worrying about potential confusion too much given the names seem kind of set now.

4

My understanding here is binutils is also typically released on a 6-month schedule, and usually a bit before LLVM does its release, so I think this problem will have solved itself by the time LLVM 17 is released, as binutils 2.41 will have already released (assuming the binutils linker supports this by then). My first instinct here is there’s only a narrow window where this is a problem, and only affecting people building LLVM from top of tree without doing the same for binutils, so I would either not land support for emitting these by default until 2.41 is released, or have an internal flag to configure whether these are emitted, and switch the default to on when 2.41 is released. In either case I think by the time LLVM 17.0.0 is finalised, we’re probably good to be emitting these by default?