Wasmtime GitHub notifications bot (May 10 2022 at 21:55): Wasmtime GitHub notifications bot (May 10 2022 at 21:55):cfallin 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 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.
Wasmtime GitHub notifications bot (May 25 2023 at 17:42):jameysharp commented on issue #2073:
I think this was addressed by #4469 so I'm going to close it. If I've missed something, feel free to re-open!
Wasmtime GitHub notifications bot (May 25 2023 at 17:42):jameysharp closed 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.
Wasmtime GitHub notifications bot (May 25 2023 at 18:15):bjorn3 commented on issue #2073:
On x86_64 we still unconditionally preserve the frame pointer even if the option is set to allow omitting them.
Wasmtime GitHub notifications bot (May 30 2023 at 17:45):fitzgen reopened 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.
Wasmtime GitHub notifications bot (May 30 2023 at 17:45):fitzgen commented on issue #2073:
Yeah this isn't fully implemented yet.
Last updated: Oct 23 2024 at 20:03 UTC