Office Hours Agenda Items

Feel free to drop in any agenda items for the monthly office hours.

Feb:

1. Updated GCC pages for 1H2025

   1. Obviously feel free to add more stuff

   2. Need similar effort for LLVM pages

2. Fortran in LLVM needs a page

3. Update on glibc mem*, str* work

4. Update on x264 findings

5. Project plans going forward (new election in the spring, who wants to step up?)

Dec:

1. vmvXr situation

   1. GCC is just treating this as a bug and has already been fixed

   2. Codegen impacts are expected to be trivial, requires vector regs to be live across calls to trigger which doesn't happen with the default ABI.

   3. LLVM is still deciding what to do

   4. May also be clarified at the ABI level

2. gcc-15 development window closed

   1. Most of Robin & my work has been submitted and is working it way through reviews

   2. Mariam (RAU)'s CRC work had been submitted well in advance, bulk of work is in

3. LLVM

   1. Separate shrink wrapping integrated upstream

   2. Stack clash protection being updated in response to Craig's feedback

4. glibc:

   1. I still need to start pushing the mem* and str* patches

5. BPI quirks

   1. Process hangs have been seen by others (golang project in particular), it's been reported and is in both the golang bug tracker and a spacemit tracker

   2. Rebuilt kernel (6.6.XX) with a modern GCC (Ventana's internal release, so gcc-14 + improvements) and I haven't seen a hang since!

Nov:

1. What to do about the vmvXr situation

   1. Does it depend on vtype or not?

   2. If it does, then that implies we'll need a vsetvl at the start of each function with vector code

   3. Unclear at this point

2. GCC 15 development window closing rapidly, will transition into bugfixing mode in ~2wks

   1. Key is that any new development must be posted for review by the deadline (Nov 17 IIRC)

   2. Robin and I have various internal patches to submit, mostly around vector performance for x264

   3. Patches already submitted have already met the deadline and are thus eligible for inclusion even if they're going through revisions

   4. Nov & December will be "general bugfixing", so any bug in bugzilla is eligible for fixing, though we reserve the right to reject things that are too risky or gaming the system

   5. Sometime in Jan we transition to regression fixes only

3. LLVM

   1. Misha's separate shrinking wrapping posted upstream for review (I think).  Should notably help 500.perlbench and 502.gcc

   2. Stack clash work is done, but engineer is engaged on other stuff right now

4. Notable work that should be landing shortly

   1. ifunc'd mem* and str*.  Andreas S. ACK'd memset with a minor fix, so I'll be submitting the rest shortly

      1. Based on work from SiFive and Rivos engineers

      2. My involvement is just the ifunc wiring

   2. CRC optimization needs minor fixes

      1. One chunk of generic code is goofy and apparently causes regressions for risc-v when fixed

      2. Looks like we need a way to check for zbkb dynamically in dejagnu harness.  Probably zbc as well

   3. Function multi-versioning for GCC

   4. Various minor changes to improve vector codegen, scheduling, etc.

5. PSAs.  BPI F3 in my tester, bootstrap & regression test every 2-3 days

   1. Right now it's always the same config, but considering alternating -march switch testing to broaden coverage (zvl)

   2. Experiencing process hangs, which look like kernel issues

Aug:

1. Reminder of GCC  patch coordination meeting every Tuesday (2:30pm UTC)

2. GNU Cauldron Prague (Sept 14-16)

3. RV Summit NA in Oct

4. RFP009 is out for bidding (LLVM performance investigation)

5. Stack Clash (GCC & LLVM)

6. CRC Work (GCC)

7. VRULL's work on narrow store feeding wider load

July:

1. RFP008

2. 2H2024 projects – especially LLVM

3. GCC Coordination Branch Discussion

   1. Keeping RISC-V backend in sync with trunk

   2. Limited cherry-picking of generic code (when it's known to help RISC-V in meaningful ways)

   3. Question we'll be discussing in patchwork meeting – late-combine changes, to include or not

June:

1. Unaligned vector loads/stores status

2. Constant Synthesis revamp.  Largely done for GCC.  Need to see if there's any significant cases for LLVM after Craig's recent fixes

3. Shrink Wrapping for LLVM

   1. Misha is diving into the EH issues and xz performance regression

4. Stack clash, later than expected, but still moving forward

   1. LLVM – Major development appears to be done.  Porting testcases from other archs to rv64 did expose one problem that Raphael is diving into now

   2. GCC – Going through internal review now

5. RFP008 – Will go through review this week

6. Flang – need a project page for LLVM.  Do we want to propose this as a contractor project?

May:

1. Jeff Law: Introduction

2. Jeff Law: Constant Synthesis (both compilers)

   1. Jeff to get Craig examples of commonly missed cases (bseti, only consistently weak idiom for LLVM)

   2. GCC needs much more work (bseti, shNadd, "uw" forms, duplicated high/low)

   3. Both compilers probably need better support for pack)

   4. Concerns about overall structure of code, but may be inherent in the problem

3. Jeff Law: Shrink Wrapping (LLVM)

   1. Just looking for high level sanity check right now

   2. Doesn't work with EH, but that's got to be an implementation detail, get the CFI notes right and it should work

   3. Interactions with push/pop?

   4. How many new code paths are showing up?  Is the code getting harder to reason about?

4. Jeff Law: Stack clash status (both compilers)

   1. External review probably 1-2 weeks out

   2. Testing with scanner to find vulnerable binaries, then test after rebuilding with new compiler

5. RFP008

   1. New language.  Jeff to review & comment

   2. Launch LLVM equivalent RFP (ADLR?)

6. ADLR & Jeff to circle back with Baylibre folks WRT LTO (they think it doesn't work)

7. IFUNCS.  How to handle case where kernel claims V, but it's actually V0.7?

   1. We can't control where the kernel for these SBCs come from

   2. We should expect those kernels to occasionally mis-represent the hardware

   3. Make glibc, gcc & llvm ifunc resolvers be reasonably defensive for these cases

   4. Avoid crashing user code in these scenarios, bad user experience

   5. Fallback to sensible default when the syscall isn't available

8. Frame pointers vs Zcmp – ABI implications and desire to unwind without CFI tables

   1. Known issue at the RVI level

   2. Distros (Fedora, Canonical, etc) likely aren't going to care. ABI for them is set, and they're likely rv64 only

   3. Would like to see ABI or extension fixed, but if that's not possible, they may do a vector extension.

9. Flang

   1. new vs old flang

   2. General need to fix flang to be cross-buildable – contractor proposall

10. LLVM Testing proposal

    1. Desire to add another configuration, who is the coordination point for this contract?

    2. Expectation is cost delta should be small (initial bring-up and ongoing resources)