Set non-leaf frame pointers on Fuchsia targets

[djkoloski]

This is part of our work to enable shadow call stack sanitization on Fuchsia, see this Fuchsia issue.

r? @tmandry

[rustbot]

These commits modify compiler targets.
(See the Target Tier Policy.)

[tmandry]

@djkoloski Is there any motivation/context you can link to?

I assume this has to do with the SCS work.

@bors r+

[bors]

📌 Commit 0637709 has been approved by tmandry

It is now in the queue for this repository.

[djkoloski]

Yeah it's SCS related. I updated the PR description with a link to Fuchsia issue.

[ilovepi]

@tmandry We plan to enable Non-Leaf frame pointers everywhere as part of Fuchsia's default options. After a thorough evaluation, we found that across most workloads in Fuchsia, there is no significant performance impact when enabling frame pointers w/ -momit-leaf-frame-pointer or the Rust equivalent of NonLeaf. The benchmarking held even for Google workloads, and open source benchmark suites, like fleetbench, eigen, and chrome benchmarks, across both X86_64 and Aarch64 CPUs.

Ideally, setting NonLeaf would be controllable through a compiler option though, and wouldn't be something you can only set in spec/base.

This isn't purely for SCS, though the motivation is the same: provide a uniform method for fast unwinding on Fuchsia.

[tmandry]

Thanks for the context @ilovepi.

[workingjubilee]

I was actually evaluating various platforms for this recently and I felt I should ask: is Fuchsia's aarch64 implementation supposed to follow the AAPCS64 ABI, or is that a "wrong question"?

@ilovepi That's good to know! Is there a convenient way for someone outside Google to view a quantified form of "no significant performance impact"? "Somewhat inconvenient, actually" is also good, really, as long as it's reachable by, uh, me.

[ilovepi]

I was actually evaluating various platforms for this recently and I felt I should ask: is Fuchsia's aarch64 implementation supposed to follow the AAPCS64 ABI, or is that a "wrong question"?

@ilovepi That's good to know! Is there a convenient way for someone outside Google to view a quantified form of "no significant performance impact"? "Somewhat inconvenient, actually" is also good, really, as long as it's reachable by, uh, me.

I'm not sure I have any documents handy that I can share externally, but benchmarking even the llvm-test suite w/ -momit-leaf over 10 runs was hard to distinguish from the noise. We ran benchmarks for a long time internally though, but even that simple experiment should give you a bit of confidence that there is a decent amount of variance in the benchmarks, even once you try to account for voltage scaling, and all the other gotchas that come w/ benchmarking. Also, FYI, there isn't much that's internal in the document or findings, I just don't think its going to be easy to share.

I've posted here what I think the take aways should be, but I did use internal benchmarking facilities to get real perf numbers using Google infrastructure, including running open source benchmarks. As a point of reference, Google enables -fno-omit-frame-pointer -momit-leaf-frame-poiner on every binary, including search, Ads, YouTube. This isn't secret sauce though, IIRC Meta, and Apple (and many other tech companies) do the same.

[workingjubilee]

Thanks! I know the numbers tend to line up for most of these cases, I was just hoping for a giant slab of collected numbers to bury people with discuss. :^) I'll get them someday.

[ilovepi]

@workingjubilee I missed the AAPCS64 ABI part of your question. As far as I know, we are. https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#the-frame-pointer spells out when leaf frames can be omitted from the frame pointer chain, which matches typical usage on other platforms. The other ABI parts that I'm aware of for Aarch64, usage of platform register and calling conventions, also comply with that document.