[llvm-dev] RISC-V LLVM sync-up call 12th Dec 2019
Alex Bradbury via llvm-dev
llvm-dev at lists.llvm.org
Thu Dec 12 06:37:44 PST 2019
For background on these calls, see
Reminder: the purpose is to co-ordinate between active contributors.
If you have support questions etc then it's best to post to llvm-dev.
We have a call each Thursday at 4pm GMT, via
I've created a shared calendar which may help in keeping track, which
is hopefully accessible at:
Issues to discuss today include the following:
* Sam has done another round of updates on ilp32e
<https://reviews.llvm.org/D70401>. As Shiva points out in the comment
thread, it seems GCC is broken when it comes to vararg handling as it
won't ensure variable doubles are aligned to 8 bytes on the stack.
* Zakk posted a patch for handling -mcpu
<https://reviews.llvm.org/D71124>. I think we need to be clear about
how this should interact with explicitly specified -march.
* Zakk has posted a patch to most -mabi for LTO and is seeking
feedback on whether this is the right approach
* Two LLD patches that may be of interest:
* Default to e_flags=0 if there are only binary input files. Needed
for FreeBSD linking. <https://reviews.llvm.org/D71101>. This seemed
sensible to me
* Handling for undefined weak symbols
<https://reviews.llvm.org/D71100>. With the RISC-V Summit I haven't
had a chance to review in detail
* There's a psabi proposal to support uleb128 relocations
requirement for constant uleb128 has been there for gcc and LLVM since
the beginning but doesn't seem to have been a blocker. It's not clear
to me what the motivating use case is? e.g. for call site encoding in
debug metadata we (both gcc /binutils and LLVM) just use udata4 rather
than uleb128, which allows us to emit a relocation when linker
relaxation is enabled.
More information about the llvm-dev