Code Size Reduction Meeting 20 th October 2020

Antitrust Policy Notice RISC-V International meetings involve participation by industry competitors, and it is the intention of RISC-V International to conduct all its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Examples of types of actions that are prohibited at RISC-V International meetings and in connection with RISC-V International activities are described in the RISC-V International Regulations Article 7 available here: https: //riscv. org/regulations/ If you have questions about these matters, please contact your company counsel.

RISC-V International RISC-V is a free and open ISA enabling a new era of processor innovation through open standard collaboration. Born in academia and research, RISC-V ISA delivers a new level of free, extensible software and hardware freedom on architecture, paving the way for the next 50 years of computing design and innovation. We are a transparent, collaborative community where all are welcomed, and all members are encouraged to participate. We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone. https: //riscv. org/risc-v-international-community-code-of-conduct/

Charter Review The code size reduction TG will develop a holistic solution to reducing code size, covering different profiles to be competitive with other core implementations of other architectures of a similar class. Priority is given to small embedded cores which often have very constrained memory sizes and so code size reduction is most important for cost reduction. Larger/higher performance cores will also benefit from reduced code size. Output The output will be improved toolchain technology to reduce code size, and also at least one ISA extension to reduce code size with toolchain support in both GCC and LLVM. If any part of any future ISA extension risks complicating the design of high performance cores, then those instructions will be in a different subset so that they can be excluded. Therefore high performance cores will also benefit from improved toolchain technology and also an ISA extension. Output from the TG could include coding recommendations to improve code size. Initial Roadmap Build a benchmark / application suite for measuring code size Collect existing proposals for code size reduction ISA extensions Improve compiler support in known weak areas, such as function call prologue/epilogue Add a new code size reduction ISA extension using encodings in line with the Instruction Encoding Allocation Policy, to address cases where the toolchain improvements alone cannot solve the code size problem Other TGs This TG will handle all aspects of making RISC-V code-size competitive. CMO, B-extension, Zfinx, EABI, Fast Interrupts and the J-extension all already have related work, but other tasks groups may as well so this is not a complete list. New TGs may be spawned as required to complete the objective. The TG will report to the toolchain and runtime standing committee, and will work with the unprivileged standing committee to ratify any ISA extensions.

Compiler resource PLCT Group from CAS 1. What about corporate assignments for upstreaming? 2. Will CAS develop both GCC and LLVM? 3. What work packages can we spec at the moment (see next slide) 4. Is this just for development of well defined features or can it include research?

Compiler work (now) 1. Repeated immediates for LUI, caused by very similar symbols being loaded 1. Deleting duplicate LUI, and/or merging constants to reduce code size 2. May cause symbols to move as the memory contents move 3. MSc project? 2. Fix Jim’s GCC task list 1. Lots of small improvements each of which will help a small amount 3. Outliner based upon the IR 1. Is there an exsiting upstreamed outliner for RISC-V? 4. Stack frame reordering to reduce zero initialisation… feasibility? 1. Move zeroed variables closer together 2. Use fewer wider stores to zero them (e. g. put zeroed bytes together) 3. In the future: use PUSHZERO over a subset of the allocated stack frame to improve performance 5. PUSH/POP 1. Already have a GCC patch for the previous versions, maybe continue with development from there?

Compiler work (future) 1. Implement other ISA extensions 2. Investigate other techniques for reducing function call prologue/epilogue 3. There must be many more…. .