See https://discourse.llvm.org/t/rfc-keep-globalvalue-guids-stable/84801
for context.

This is a non-functional change which just changes the interface of
GlobalValue, in preparation for future functional changes. This part
touches a fair few users, so is split out for ease of review. Future
changes to the GlobalValue implementation can then be focused purely on
that class.

This does the following:

* Rename GlobalValue::getGUID(StringRef) to
  getGUIDAssumingExternalLinkage. This is simply making explicit at the
  callsite what is currently implicit.
* Where possible, migrate users to directly calling getGUID on a
  GlobalValue instance.
* Otherwise, where possible, have them call the newly renamed
  getGUIDAssumingExternalLinkage, to make the assumption explicit.


There are a few cases where neither of the above are possible, as the
caller saves and reconstructs the necessary information to compute the
GUID themselves. We want to migrate these callers eventually, but for
this first step we leave them be.

Currently, an AsmPrinterHandler has several methods that allow to
dynamically hook in unwind or debug info emission, e.g. at begin/end of
every function or instruction. The class hierarchy and the actually
overridden functions are as follows:

    (SymSz=setSymbolSize, mFE=markFunctionEnd, BBS=BasicBlockSection,
     FL=Funclet; b=beginX, e=endX)
                          SymSz   Mod Fn  mFE BBS FL  Inst
    AsmPrinterHandler     -       -   -   -   -   -   -
    ` PseudoProbeHandler  -       -   -   -   -   -   -
    ` WinCFGuard          -       e   e   -   -   -   -
    ` EHStreamer          -       -   -   -   -   -   -
      ` DwarfCFIException -       e   be  -   be  -   -
      ` ARMException      -       -   be  e   -   -   -
      ` AIXException      -       -   e   -   -   -   -
      ` WinException      -       e   be  e   -   be  -
      ` WasmException     -       e   be  -   -   -   -
    ` DebugHandlerBase    -       b   be  -   be  -   be
      ` BTFDebug          -       e   -   -   -   -   b
      ` CodeViewDebug     -       be  -   -   -   -   b
      ` DWARFDebug        yes     be  -   -   -   -   b

Doing virtual function calls per instruction is costly and useless when
the called function does nothing.

This commit performs the following clean-up/improvements:

- PseudoProbeHandler is no longer an AsmPrinterHandler -- it used
nothing of its functionality to hook in at the possible points. This
avoids virtual function calls when a pseudo probe printer is present.

- DebugHandlerBase is no longer an AsmPrinterHandler, but a separate
base class. DebugHandlerBase is the only remaining "hook" for begin/end
instruction and setSymbolSize (only used by DWARFDebug). begin/end for
function and basic block sections are never overriden and therefore are
no longer virtual. (Originally I intended there to be only one debug
handler, but BPF as the only target supports two at the same time: DWARF
and BTF.)

- AsmPrinterHandler no longer has begin/end instruction and
setSymbolSize hooks -- these were only used by DebugHandlerBase. This
avoid iterating over handlers in every instruction.

    AsmPrinterHandler     Mod Fn  mFE BBS FL
    ` WinCFGuard          e   e   -   -   -
    ` EHStreamer          -   -   -   -   -
      ` DwarfCFIException e   be  -   be  -
      ` ARMException      -   be  e   -   -
      ` AIXException      -   e   -   -   -
      ` WinException      e   be  e   -   be
      ` WasmException     e   be  -   -   -

                          SymSz   Mod Fn  BBS Inst
    DebugHandlerBase      -       b   be  be  be
    ` BTFDebug            -       e           b
    ` CodeViewDebug       -       be          b
    ` DWARFDebug          yes     be          b

    PseudoProbeHandler (no shared methods)

To continue allowing external users (e.g., Julia) to hook in at every
instruction, a new method addDebugHandler is exposed.

This results in a performance improvement, especially in the -O0 -g0
case with unwind information (e.g., JIT baseline).

Despite previous effort {D148569} to avoid screwing up existing disrminator field, I'm still seeing some call probes getting a non-zero discriminator eventually in non-FS mode. It could be related to callsite merge. While they are investigated I'm disabling discriminator emission for non-FS mode. This avoids breaking the compatiblity with older tools like llvm-profgen and bolt.

Reviewed By: wenlei

Differential Revision: https://reviews.llvm.org/D150625

Encoding FS discriminators for block probes. Decoding them correspondingly.

The encoding/decoding of FS discriminators are conditional, only for probes with a non-zero discriminator. This saves encoding size, also ensures downwards-compatiblity.

Reviewed By: wenlei

Differential Revision: https://reviews.llvm.org/D147651

This change improves FS discriminators in the following ways:
(1) use call-stack debug information in the the to generate
discriminators: the same (src/line) DILs can now have same
discriminator value if they come from different call-stacks.
This effectively increases the usable discriminator values
for each round of FS discriminator pass.
(2) don't generate the FS discriminator for meta instructions
(i.e. instructions not emitted). This reduces the number
discriminators conflicts (for the case we run out of discriminator
bits for that pass).
(3) use less expensive hashing of xxHash64.

These improvements should bring better performance for FSAFDO
and they should be used by default. But this change creates
incompatible FS discriminators. For the iterative profile users,
they might see a performance drop in the first release with
this change (due to the fact that the profiles have the old
discriminators and the compiler uses the new discriminator).
We have measured that this is not more than 1.5% on several
benchmarks. Note the degradation should be gone in the second
release and one should expect a performance gain over the binary
without this change.

One possible solution to the iterative profile issue would be
separating discriminators for profile-use and the ones emitted to
the binary. This would require a mechanism to allow two sets of
discriminators to be maintained and then phasing out the first
approach. This is too much churn in the compiler and the
performance implications do not seem to be worth the effort.

Instead, we put the changes under an option so iterative profile
users can do a gradual rollout of this change. We will make the
option default value to true in a later patch and eventually
purge this option from the code base.

Differential Revision: https://reviews.llvm.org/D145171

Currently pseudo probe encoding for a function is like:
	- For the first probe, a relocation from it to its physical position in the code body
	- For subsequent probes, an incremental offset from the current probe to the previous probe

The relocation could potentially cause relocation overflow during link time. I'm now replacing it with an offset from the first probe to the function start address.

A source function could be lowered into multiple binary functions due to outlining (e.g, coro-split). Since those binary function have independent link-time layout, to really avoid relocations from .pseudo_probe sections to .text sections, the offset to replace with should really be the offset from the probe's enclosing binary function, rather than from the entry of the source function. This requires some changes to previous section-based emission scheme which now switches to be function-based. The assembly form of pseudo probe directive is also changed correspondingly, i.e, reflecting the binary function name.

Most of the source functions end up with only one binary function. For those don't, a sentinel probe is emitted for each of the binary functions with a different name from the source. The sentinel probe indicates the binary function name to differentiate subsequent probes from the ones from a different binary function. For examples, given source function

```
Foo() {
  …
  Probe 1
  …
  Probe 2
}
```

If it is transformed into two binary functions:

```
Foo:
   …

Foo.outlined:
   …
```

The encoding for the two binary functions will be separate:

```

GUID of Foo
  Probe 1

GUID of Foo
  Sentinel probe of Foo.outlined
  Probe 2
```

Then probe1 will be decoded against binary `Foo`'s address, and Probe 2 will be decoded against `Foo.outlined`. The sentinel probe of `Foo.outlined` makes sure there's not accidental relocation from `Foo.outlined`'s probes to `Foo`'s entry address.

On the BOLT side, to be minimal intrusive, the pseudo probe re-encoding sticks with the old encoding format. This is fine since unlike linker, Bolt processes the pseudo probe section as a whole and it is free from relocation overflow issues.

The change is downwards compatible as long as there's no mixed use of the old encoding and the new encoding.

Reviewed By: wenlei, maksfb

Differential Revision: https://reviews.llvm.org/D135912
Differential Revision: https://reviews.llvm.org/D135914
Differential Revision: https://reviews.llvm.org/D136394

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D121332

Md5 hashing is expansive. Using a hash map to look up already computed GUID for dwarf names. Saw a 2% build time improvement on an internal large application.

Reviewed By: wenlei

Differential Revision: https://reviews.llvm.org/D108722

Previously we reliedy on pseudo probe descriptors to look up precomputed GUID during probe emission for inlined probes. Since we are moving to always using unique linkage names, GUID for functions can be computed in place from dwarf names. This eliminates the need of importing pseudo probe descs in thinlto, since those descs should be emitted by the original modules.

This significantly reduces thinlto memory footprint in some extreme case where the number of imported modules for a single module is massive.

Test Plan:

Reviewed By: wenlei

Differential Revision: https://reviews.llvm.org/D105248