Don't force-enable frame pointers when generating debug info

[nikomatsakis]

In #47152, we decided to add a flag to force enable frame pointers (that is, to prevent the compiler from optimizing them away). This flag was to be insta-stable because it is needed, e.g. to help profilers like perf that need to reconstruct the stack. @dotdash then came back with a few proposed changes. Unfortunately, they were never able to finalize the rebase, and the PR was closed by triage for inactivity. This is where you come in, dear reader! Perhaps you can help us!

There was some dispute about what the final interface ought to be though. @dotdash proposed -Comit-frame-pointer=[yes|no], but @Mark-Simulacrum proposed -Cframe-pointers=[auto, yes, no], which seems logical enough.

However we say it, the default behavior (when user says nothing) probably wants to be:

• If debuginfo is enabled, keep them.
• If not optimizing, keep them.
• Follow behavior of either gcc or clang:
  • GCC has the -fomit-frame-pointer option, default off on "32-bit GNU/Linux x86 and 32-bit Darwin x86 targets", but otherwise on it seems if optimizing.
  • clang always retains frame pointers on darwin by default
  • cl.exe will always keep frame pointers by default for unoptimized builds

[nikomatsakis]

cc @rust-lang/compiler -- we should settle on a plan here, no?

[nagisa]

-Cframe-pointers=val matches our current direction of CLI design. We should change to that ASAP if we want to keep the compatibility.

The defaults can always be changed later, though. The default should be specified in the target files.

I’ll fiddle with this.

[jonhoo]

Should this be closed given that #48786 has landed?