5 ms·

tl;dr: maybe frame pointer omission was premature

pengaru 4y ago
> tl;dr: maybe frame pointer omission was premature Not really. More like "frame pointer omission made sense on the severely register-starved i386, today we can afford to spare %rbp for substantial debugging/profiling advantages"
- cesarb 4y ago
  > frame pointer omission made sense on the severely register-starved i386 For those who lack the context: 32-bit x86 uses only 3 bits for the register specification, so it can address only 8 general-purpose registers. Of these, one is reserved for the stack pointer, leaving only 7 general-purpose registers available, or 6 if you reserve one of them for the frame pointer. For 64-bit x86, AMD added one extra register specification bit on a prefix byte, so at the cost of an extra instruction byte, the instruction can address an extra 8 general-purpose registers, for a total of 15 plus the stack pointer, or 14 if you also reserve the frame pointer. That is: on 64-bit x86, you have with frame pointers twice as many available registers as 32-bit x86 has without frame pointers. And these registers are double the size, so a 64-bit variable which needs two registers on 32-bit x86 needs only one register on 64-bit x86, so the effect can be more than just a doubling. And then you have 64-bit ARM, which uses five bits for the register specification... (32-bit ARM already used four bits, so it was never as register-starved as 32-bit x86; and RISC-V uses five bits for both 32-bit and 64-bit.) I don't think getting rid of frame pointer omission would be viable if Fedora still supported 32-bit x86. Once they got rid of most of that compatibility (there are still 32-bit compatibility libraries, necessary only for some old binary-only code and for Wine, and I believe Wine will sooner or later not need them anymore), making this change became more acceptable.
  - michel-slm 4y ago
    > That is: on 64-bit x86, you have with frame pointers twice as many available registers as 32-bit x86 has without frame pointers Indeed. > I don't think getting rid of frame pointer omission would be viable if Fedora still supported 32-bit x86 Fedora still supports it (e.g. packages are still built for i686, and you can install them on x86_64) though it has dropped 32-bit ARM. But the change to reenable frame pointers will not be applied to 32-bit x86 builds.

> tl;dr: maybe frame pointer omission was premature Not really. More like "frame pointer omission made sense on the severely register-starved i386, today we can afford to spare %rbp for substantial debugging/profiling advantages"

cesarb 4y ago
> frame pointer omission made sense on the severely register-starved i386 For those who lack the context: 32-bit x86 uses only 3 bits for the register specification, so it can address only 8 general-purpose registers. Of these, one is reserved for the stack pointer, leaving only 7 general-purpose registers available, or 6 if you reserve one of them for the frame pointer. For 64-bit x86, AMD added one extra register specification bit on a prefix byte, so at the cost of an extra instruction byte, the instruction can address an extra 8 general-purpose registers, for a total of 15 plus the stack pointer, or 14 if you also reserve the frame pointer. That is: on 64-bit x86, you have with frame pointers twice as many available registers as 32-bit x86 has without frame pointers. And these registers are double the size, so a 64-bit variable which needs two registers on 32-bit x86 needs only one register on 64-bit x86, so the effect can be more than just a doubling. And then you have 64-bit ARM, which uses five bits for the register specification... (32-bit ARM already used four bits, so it was never as register-starved as 32-bit x86; and RISC-V uses five bits for both 32-bit and 64-bit.) I don't think getting rid of frame pointer omission would be viable if Fedora still supported 32-bit x86. Once they got rid of most of that compatibility (there are still 32-bit compatibility libraries, necessary only for some old binary-only code and for Wine, and I believe Wine will sooner or later not need them anymore), making this change became more acceptable.
- michel-slm 4y ago
  > That is: on 64-bit x86, you have with frame pointers twice as many available registers as 32-bit x86 has without frame pointers Indeed. > I don't think getting rid of frame pointer omission would be viable if Fedora still supported 32-bit x86 Fedora still supports it (e.g. packages are still built for i686, and you can install them on x86_64) though it has dropped 32-bit ARM. But the change to reenable frame pointers will not be applied to 32-bit x86 builds.