Re: [RFC] RISCV: Align using RVC insns

[Patrick O'Neill <patrick@rivosinc.com>]

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.

Thanks,
Patrick