[RFC] RISCV: Align using RVC insns

[Andrew Waterman]

On Mon, Mar 28, 2022 at 5:46 PM Patrick O'Neill <patrick@rivosinc.com> wrote:
>
>
> On 3/28/22 17:17, Palmer Dabbelt wrote:
> > On Mon, 28 Mar 2022 15:19:41 PDT (-0700), Patrick O'Neill wrote:
> >>
> >> On 3/28/22 00:54, Jan Beulich wrote:
> >>> On 26.03.2022 00:15, Patrick O'Neill wrote:
> >>>> Currently, .align and .balign directives only use nops to achieve
> >>>> alignment. On RVC targets, the linker can selectively compress
> >>>> instructions to achieve alignment without introducing nops.
> >>>>
> >>>> This increases the code size of unlinked binaries since instruction
> >>>> compression is deferred to the linker. Linked binaries with align
> >>>> directives may be smaller/run faster due to less nops.
> >>>>
> >>>> Binaries without align directives should be unaffected by this change.
> >>>>
> >>>> This change requires adding a reloc for compressable instructions. The
> >>>> addend of that reloc stores the compressed instruction's opcode.
> >>>>
> >>>> Signed-off-by: Patrick O'Neill <patrick@rivosinc.com>
> >>> May I ask where the specification for this lives? I've just pulled down
> >>> the latest version of the psABI, but that doesn't even mention the new
> >>> relocation type you use here. Going over
> >>> https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues also didn't
> >>> turn up anything obvious.
> >>>
> >>> Jan
> >>>
> >> Jan,
> >>
> >> Thank you for the link, I just opened a pull request proposing the
> >> addition of this relocation type.
> >
> > IMO it's really too early to have a meaningful discussion about
> > putting this in the spec.  There's a handful of complicated
> > interactions this has with the rest of the stack, and we need to sort
> > these out before we know if this is a good idea (or exactly what
> > should be in the spec).  Specifically:
> >
> > * This is going to massively increase link time, as there'll be a lot
> >  more relaxed relocations.  We've got a quadratic time implementation,
> >  so things will get bad (and things that are already bad will get very
> >  bad).  I think it's possible to make linker relaxation linear time,
> >  but that has yet to be proved out.
> > * We likely want some compiler assistance in picking which instructions
> >  to compress.  There's a bunch of ways to do that, but it'll
> >  probably require some assembler syntax and may change the relocation
> >  definition.
> > * We're probably not describing the right alignment constraints: for
> >  some of these systems we're really trying to say "avoid crossing
> >  a cache line boundary", which is inefficient to encode as an alignment
> >  constraint (it's really "don't misalign", not "align").  That might
> >  not be entirely required, as some systems do just need regular
> >  alignment, but we should at least make sure this new scheme avoids
> >  obviously breaking anything.
> >
> > That said, this idea has been bounced around a bunch of times before
> > without anything making it to the lists so I figured it'd be best to
> > just send the RFC -- at least it's a start, and all those other
> > problems are sort of their own concerns.  Maybe we'll get lucky and
> > one of the other implementations floating around had some smart
> > solutions to these problems, but I've got a feeling this is going to
> > be more than a bit of work.
> I'll start work on the linear link time implementation.

Cool.  That will be a significant improvement, irrespective of how we
proceed with this RFC.

>
> Thanks,
> Patrick