Unaligned access trade-offs for SFrame FRE layout

[Indu Bhagat <indu.bhagat@oracle.com>]

TL;DR: Thinking and experimenting a bit on the possible approaches for 
avoiding unaligned accesses in the SFrame FRE layout (in SFrame V3), I 
am not convinced that avoiding unaligned accesses for performance is 
worth it.  IMO, forsaking compactness for avoiding unaligned accesses is 
not a good trade off for SFrame.

Problem Statement
On architectures such as x86_64, AArch64, and s390x, unaligned memory 
accesses are handled transparently by the hardware but incur a 
performance penalty. The objective of this analysis is to evaluate if 
these unaligned accesses can be eliminated from the SFrame FRE layout 
and if doing so provides a net performance benefit.

The central challenge is that any alternative must demonstrate a clear
performance improvement while avoiding significant size overhead. 
Introducing "bloat" to the format to solve a potential performance issue 
is a poor trade-off.

Source of unaligned accesses in SFrame FRE
  - (#1) Access to the SFrame FRE start address (sfre_start_address)
  - (#2) Access to the SFrame FRE stack offsets,  This is varlen data 
tailing SFrame FRE top-level members (sfre_start_address and FRE info), 
usually interpreted as stack offsets)

(Note that in the SFrame specification, SFrame Header, and SFrame FDE 
(function descriptor entry) have aligned accesses.)

Updated notes on the various approaches and respective evaluation notes 
on the wiki page:
https://sourceware.org/binutils/wiki/sframe/sframev3todo#Avoid_unaligned_accesses

Summary of Approaches and Analysis/Notes
Unaligned accesses may mean lower performance, but the alternative we 
pick must at least provide better performance.  It is also important 
that the chosen approach does not add bloat to the format.  Avoiding 
unaligned accesses at the expense of bloating up the format is not a 
good idea IMO.

Approach 1a: Bucketed members
  Pros: Negligible bloat.
  Cons: 1. Writing out the FRE data is somewhat more involved. Affects
   assemblers, linkers. 2. For the common case though, accessing stack 
offsets now needs more memory accesses per FRE.  This approach will not 
bring clear performance benefits; the additional complexity in SFrame 
readers and writers is not justified then either.

Approach 1b: Bucketed members with Index
  Cons: Significant bloat (~30%).

Approach 2: De-duplicated "stack offsets"
  Pros: Will help reduce the size of SFrame sections.
  Cons: 1. SFrame FRE layout is designed to be flexible so that it can
   serve needs of new ABIs:  The varlen data is interpreted as stack 
offsets on x86_64, and AArch64, but may not be the case for other ABIs. 
De-duplicating non-structured data is not meaningful. 2. Writing out the 
FRE data is quite more involved, increasing the complexity in Toolchain.

Approach 3: Good old basic padding
  Cons: Significant bloat (~22%).  Performance win arguable as well.

IMO, none of these approaches provide viable way to move forward. The 
proposed methods either fail to deliver the desired clear performance 
gain or introduce a significant size penalty or complexity, which is an 
unacceptable trade-off.

Would like to gather inputs from the interested folks on this. Please 
take a look and chime in.  Other ideas welcome.

Thanks