[PATCH v6 01/13] ARC: ABI Implementation

[Vineet Gupta]

On 5/27/20 11:26 AM, Adhemerval Zanella via Libc-alpha wrote:
> +ENTRY (__longjmp)
> +
> +	ld_s r13,   [r0]
> +	ld_s r14,   [r0,4]
> +	ld   r15,   [r0,8]
> +	ld   r16,   [r0,12]
> +	ld   r17,   [r0,16]
> +	ld   r18,   [r0,20]
> +	ld   r19,   [r0,24]
> +	ld   r20,   [r0,28]
> +	ld   r21,   [r0,32]
> +	ld   r22,   [r0,36]
> +	ld   r23,   [r0,40]
> +	ld   r24,   [r0,44]
> +	ld   r25,   [r0,48]
> +
> +	ld   blink, [r0,60]
> +	ld   fp,    [r0,52]
> +	ld   sp,    [r0,56]
> +
> +	mov.f  r0, r1	; get the setjmp return value(due to longjmp) in place
> +
> +	j.d    [blink]	; to caller of setjmp location, right after the call
> +	mov.z  r0, 1	; can't let setjmp return 0 when it is due to longjmp
> +
> +END (__longjmp)

So wanted to pick your brains on this thing. While longjmp is not necessarily an
application hotspot, it seems bulk load/store can in general benefit from with
ARCv2 double load/store instructions LDD/STD which work with register pairs.

So we could have 2 variants which compile differently to one runtime
implementation or better still have 2 runtime implementations which could be
switched to using hwcaps (which I can add to kernel). Does that require IFUNC
which ARC toolchain doesn't support ATM.

-Vineet