peterhuene labeled Issue #2073:
Feature
When permitted by the ABI and optimization goals, implement omitting frame pointers in Cranelift and add an option for forcing the establishment of frame pointers.
Benefit
Some supported ABIs do not need a frame pointer for debugging or unwinding purposes. Moderns compilers that target such ABIs tend to omit the frame pointer by default or when doing so is permissible (e.g. based on an optimization goal).
Omitting the frame pointer might free up an additional general purpose register to use (e.g. RBP for x86-64). It may also lead to more compact and efficient code depending on the function.
See #1149 and #1105 for some other discussions around this issue.
Implementation
As frame pointers might be useful to some third-party tools, add a Cranelift compiler option for forcing the use of frame pointers in prologues/epilogues (an analogue to
-fno-omit-frame-pointer
). It should default tofalse
. For ABIs where a frame pointer is required, this option will have no effect.For ABIs where it is permissible to do so, respect the option not being present by omitting the establishment of the frame pointer in the prologue and also the restoring the previous frame pointer in the epilogue.
Note that, depending on the offsets used relative to a frame pointer vs. the stack pointer, omitting a frame pointer might impact code size by forcing encodings of larger offsets relative to the stack pointer. Ultimately whether or not a frame pointer is omitted should be based on the impact to the desired optimization goals. Currently, some ABIs, like Windows and SystemV for x86-64, always establish a frame pointer but are addressing the stack relative to the stack pointer, so omitting the frame pointer won't have any negative impact on code generation size.
Also note that for certain ABIs, dynamic stack allocations (e.g.
alloca
) may require a "frame pointer" register to denote the base address of the static part of the frame as if it were the stack pointer prior to the first dynamic stack pointer adjustment. Locals and arguments could be addressed as a positive relative offset from this frame pointer register. Windows x64, for example, calls this a frame pointer for the purposes of unwinding.Alternatives
The alternative is to do what Cranelift does now which is to always establish a frame pointer, which may lead to less efficient code or otherwise unnecessary instructions for every compiled function.
peterhuene opened Issue #2073:
Feature
When permitted by the ABI and optimization goals, implement omitting frame pointers in Cranelift and add an option for forcing the establishment of frame pointers.
Benefit
Some supported ABIs do not need a frame pointer for debugging or unwinding purposes. Moderns compilers that target such ABIs tend to omit the frame pointer by default or when doing so is permissible (e.g. based on an optimization goal).
Omitting the frame pointer might free up an additional general purpose register to use (e.g. RBP for x86-64). It may also lead to more compact and efficient code depending on the function.
See #1149 and #1105 for some other discussions around this issue.
Implementation
As frame pointers might be useful to some third-party tools, add a Cranelift compiler option for forcing the use of frame pointers in prologues/epilogues (an analogue to
-fno-omit-frame-pointer
). It should default tofalse
. For ABIs where a frame pointer is required, this option will have no effect.For ABIs where it is permissible to do so, respect the option not being present by omitting the establishment of the frame pointer in the prologue and also the restoring the previous frame pointer in the epilogue.
Note that, depending on the offsets used relative to a frame pointer vs. the stack pointer, omitting a frame pointer might impact code size by forcing encodings of larger offsets relative to the stack pointer. Ultimately whether or not a frame pointer is omitted should be based on the impact to the desired optimization goals. Currently, some ABIs, like Windows and SystemV for x86-64, always establish a frame pointer but are addressing the stack relative to the stack pointer, so omitting the frame pointer won't have any negative impact on code generation size.
Also note that for certain ABIs, dynamic stack allocations (e.g.
alloca
) may require a "frame pointer" register to denote the base address of the static part of the frame as if it were the stack pointer prior to the first dynamic stack pointer adjustment. Locals and arguments could be addressed as a positive relative offset from this frame pointer register. Windows x64, for example, calls this a frame pointer for the purposes of unwinding.Alternatives
The alternative is to do what Cranelift does now which is to always establish a frame pointer, which may lead to less efficient code or otherwise unnecessary instructions for every compiled function.
github-actions[bot] commented on Issue #2073:
Subscribe to Label Action
cc @bnjbvr
<details>
This issue or pull request has been labeled: "cranelift"Thus the following users have been cc'd because of the following labels:
- bnjbvr: cranelift
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
peterhuene edited Issue #2073:
Feature
When permitted by the ABI and optimization goals, implement omitting frame pointers in Cranelift and add an option for forcing the establishment of frame pointers.
Benefit
Some supported ABIs do not need a frame pointer for debugging or unwinding purposes. Moderns compilers that target such ABIs tend to omit the frame pointer by default or when doing so is permissible (e.g. based on an optimization goal).
Omitting the frame pointer might free up an additional general purpose register to use (e.g. RBP for x86-64). It may also lead to more compact and efficient code depending on the function.
See #1149 and #1105 for some other discussions around this issue.
Implementation
As frame pointers might be useful to some third-party tools, add a Cranelift compiler option for forcing the use of frame pointers in prologues/epilogues (an analogue to
-fno-omit-frame-pointer
). It should default tofalse
. For ABIs where a frame pointer is required, this option will have no effect.For ABIs where it is permissible to do so, respect the option not being present by omitting the establishment of the frame pointer in the prologue and also the restoring the previous frame pointer in the epilogue.
Note that, depending on the offsets used relative to a frame pointer vs. the stack pointer, omitting a frame pointer might impact code size by forcing encodings of larger offsets relative to the stack pointer. Ultimately whether or not a frame pointer is omitted should be based on the impact to the desired optimization goals. Currently in Cranelift, some ABIs, like Windows and SystemV for x86-64, always establish a frame pointer but are addressing the stack relative to the stack pointer, so omitting the frame pointer won't have any negative impact on code generation size.
Also note that for certain ABIs, dynamic stack allocations (e.g.
alloca
) may require a "frame pointer" register to denote the base address of the static part of the frame as if it were the stack pointer prior to the first dynamic stack pointer adjustment. Locals and arguments could be addressed as a positive relative offset from this frame pointer register. Windows x64, for example, calls this a frame pointer for the purposes of unwinding.Alternatives
The alternative is to do what Cranelift does now which is to always establish a frame pointer, which may lead to less efficient code or otherwise unnecessary instructions for every compiled function.
xmartinez commented on Issue #2073:
As frame pointers might be useful to some third-party tools, add a Cranelift compiler option for forcing the use of frame pointers in prologues/epilogues (an analogue to -fno-omit-frame-pointer). It should default to false.
Could this default to
true
, instead? I.e., could the compiler use frame pointers unless explicitly asked not to? (At least in Linux targets that are not register-starved, e.g., x86-64).As already mentioned by @bjorn3 (https://github.com/bytecodealliance/wasmtime/issues/1105#issuecomment-664620661), some tools such as Linux
perf
andbpftrace
rely or can benefit from frame pointers for efficient user-space stack walking. These tools can be used to profile unmodified binaries.Omitting frame pointers by default will decrease the out-of-the-box usefulness of these tools (as getting proper stack traces might require a recompilation of the traced binaries and its dependencies).
peterhuene commented on Issue #2073:
I'm fine with the default in Cranelift being
true
, but I think Wasmtime should set such an option tofalse
by default, possibly turning it totrue
for debug code generation.
yurydelendik commented on Issue #2073:
FWIW if stack unwinding implemented right it is possible to still support backtrace/unwinding type of scenarios.
bjorn3 commented on Issue #2073:
DWARF based unwinding results in much larger perf profiles as it needs to copy a big chunk of the stack for offline unwinding. The amount of stack copied is fixed with the max configurable soze being 50kb. If the stack is deeper, frames will be missing from the backtrace
In addition it takes much longer to process the profiles when using DWARF unwinding.
Last updated: Dec 23 2024 at 12:05 UTC