[PATCH 8/8] s390: Store SFrame CFA offset adjusted and scaled down

[Indu Bhagat]

On 4/22/25 7:33 AM, Jens Remus wrote:
> Hello Indu,
> 
> thank you for the review feedback!
> 
> On 17.04.2025 20:53, Indu Bhagat wrote:
>> On 4/2/25 9:12 AM, Jens Remus wrote:
>>> In SFrame V2 the size of the one to three offsets following a SFrame FDE
>>
>> "following an SFrame FRE"
>>
>> Also, I would avoid saying "of the one to three offsets".  The format
>> by itself does not limit the number of offsets, though for all current
>> practical usages, we see 1-3 offsets.  It is, of course, not
>> recommended to use the format to encode large number of offsets.
>>
>> So it can be confusing to see that in git logs.
> 
> Sure.  Same as for the preceding commit.
> 
>>> can be either signed 8-bit, 16-bit, or 32-bit integer, which the largest
>>> offset determining their size:
>>>    1. CFA offset from CFA base register
>>>    2. RA (stack save slot) offset from CFA, usually -48 on s390x if 
>>> saved
>>>    3. FP (stack save slot) offset from CFA, usually -72 on s390x if 
>>> saved
>>> The FP and RA offsets from CFA, when FP/RA saved on the stack, usually
>>> have fixed values that fit into signed 8-bit SFrame offsets.  Likewise
>>> the DWARF register numbers on s390x of general registers (GR; 0-15) and
>>> floating-point registers (FPR; 16-31), when FP/RA saved in registers.
>>> With that the CFA offset from CFA base register has the greatest impact
>>> on the signed SFrame offset size.
>>>
>>> The s390x ELF ABI defines the stack pointer (SP) to be 8-byte aligned
>>> [1] and the CFA as SP at call site + 160 [2].  The CFA offset from CFA
>>> base register is therefore always a multiple of 8.
>>>
>>> On S390 store the SFrame CFA offset from CFA base register scaled down
>>> by the s390x-specific CFA alignment factor of 8, in addition to the
>>> adjustment by the s390x-specific CFA adjustment of -160, to further
>>> improve the use of signed 8-bit SFrame offsets.  This is similar to the
>>> DWARF data alignment factor getting factored out from certain offsets
>>> stored in DWARF CFI.
>>>
>>> [1]: s390x ELF ABI, sections "Register Roles" and "Stack Frame
>>>       Allocation", https://github.com/IBM/s390x-abi/releases
>>> [2]: s390x ELF ABI, commit 4e38ad9c8a88 ("Document the CFA"),
>>>       https://github.com/IBM/s390x-abi/commit/4e38ad9c8a88
> 
>>> diff --git a/libsframe/doc/sframe-spec.texi b/libsframe/doc/sframe- 
>>> spec.texi
> 
>>> @@ -838,12 +838,15 @@ Hence, in summary:
>>>   Irrespective of the ABI, the first stack offset is always used to 
>>> locate the
>>>   CFA.  On S390 the value of the offset is stored adjusted by the 
>>> S390-specific
>>> -@code{SFRAME_S390_CFA_OFFSET_ADJUSTMENT} to enable the use of signed 
>>> 8-bit
>>> -offsets on S390.
>>> +@code{SFRAME_S390_CFA_OFFSET_ADJUSTMENT} and scaled down by the 
>>> S390-specific
>>> +@code{SFRAME_S390_CFA_OFFSET_ALIGNMENT_FACTOR}, to enable and 
>>> improve the use
>>> +of signed 8-bit offsets on S390.
>>>   S390-specific helpers @code{SFRAME_V2_FRE_S390_CFA_OFFSET_ENCODE} and
>>> -@code{SFRAME_V2_FRE_S390_CFA_OFFSET_DECODE} are provided to perform 
>>> and undo the
>>> -adjustment.  The CFA offset can therefore be interpreted as:
>>> -CFA = @code{BASE_REG} + offset1 - 
>>> @code{SFRAME_S390_CFA_OFFSET_ADJUSTMENT}
>>> +@code{SFRAME_V2_FRE_S390_CFA_OFFSET_DECODE} are provided to perform 
>>> or undo the
>>> +adjustment and scaling.  The CFA offset can therefore be interpreted 
>>> as:
>>> +CFA = @code{BASE_REG}
>>> +    + (offset1 * @code{SFRAME_S390_CFA_OFFSET_ALIGNMENT_FACTOR})
>>> +    - @code{SFRAME_S390_CFA_OFFSET_ADJUSTMENT}
>>>   or
>>>   CFA = @code{BASE_REG} + 
>>> @code{SFRAME_V2_FRE_S390_CFA_OFFSET_DECODE(offset1)}.
>>>   The identification of the @code{BASE_REG} is done by using the
>>
>> Was it considered to apply the scaling down for all stack offsets
>> uniformly ?  It looks to me that the benefit of that will be simply
>> uniformity, and not so much size benefits.  But I am curious to know
>> your opinion (or any experimentation) on this.
> 
> On s390x GCC and Clang adhere to the "Register save area usage example"
> shown in the s390x ELF ABI.  That is the "preferred" FP register r11 is
> always saved at offset -72 from CFA and the RA register r14 at offset
> -48, if saved on the stack.
> 
> Both -72 and -48 fit into a signed 8-bit SFrame offset.  Therefore I did
> not see any benefit to apply a scaling as I did for the CFA offset from
> CFA base register.
> 
> Furthermore the encoding of DWARF register numbers as offsets (see patch
> "[PATCH 4/8] s390: Represent FP/RA saved in register in SFrame") limits
> the possibility to apply such scaling.  As the LSB is used as indicator
> it could only be done >>2 instead of >>3.
> 
> If SFrame V3 would represent register save slot offsets and register
> numbers in a different way, then it may make sense to consider to apply
> such as an arch-dependent scaling similar to the DWARF data alignment
> factor uniformly to all offsets (e.g. CFA offset, RA offset, FP offset).
> 

Makes sense.