Re: [RFC] RISCV: Align using RVC insns

[Palmer Dabbelt <palmer@dabbelt.com>]

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.