RISC-V LLVM sync-up call 12th Dec 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:
  * <https://calendar.google.com/calendar/b/1?cid=bG93cmlzYy5vcmdfMG41cGtlc2ZqY25wMGJoNWhwczFwMGJkODBAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ>
  * <https://calendar.google.com/calendar/ical/lowrisc.org_0n5pkesfjcnp0bh5hps1p0bd80%40group.calendar.google.com/public/basic.ics>

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
<https://github.com/riscv/riscv-elf-psabi-doc/pull/124>. The
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.