llvm-project/llvm/test/LTO
Matthias Braun 850d53a197 LTO: Decide upfront whether to use opaque/non-opaque pointer types
LTO code may end up mixing bitcode files from various sources varying in
their use of opaque pointer types. The current strategy to decide
between opaque / typed pointers upon the first bitcode file loaded does
not work here, since we could be loading a non-opaque bitcode file first
and would then be unable to load any files with opaque pointer types
later.

So for LTO this:
- Adds an `lto::Config::OpaquePointer` option and enforces an upfront
  decision between the two modes.
- Adds `-opaque-pointers`/`-no-opaque-pointers` options to the gold
  plugin; disabled by default.
- `--opaque-pointers`/`--no-opaque-pointers` options with
  `-plugin-opt=-opaque-pointers`/`-plugin-opt=-no-opaque-pointers`
  aliases to lld; disabled by default.
- Adds an `-lto-opaque-pointers` option to the `llvm-lto2` tool.
- Changes the clang driver to pass `-plugin-opt=-opaque-pointers` to
  the linker in LTO modes when clang was configured with opaque
  pointers enabled by default.

This fixes https://github.com/llvm/llvm-project/issues/55377

Differential Revision: https://reviews.llvm.org/D125847
2022-06-01 18:05:53 -07:00
..
AArch64 Support the min of module flags when linking, use for AArch64 BTI/PAC-RET 2022-04-13 09:31:51 +02:00
ARM
Resolution/X86 LTO: Decide upfront whether to use opaque/non-opaque pointer types 2022-06-01 18:05:53 -07:00
X86 LTO: Decide upfront whether to use opaque/non-opaque pointer types 2022-06-01 18:05:53 -07:00