850d53a197
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
8 lines
169 B
LLVM
8 lines
169 B
LLVM
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
|
|
target triple = "x86_64-unknown-linux-gnu"
|
|
|
|
define i64 @foo(ptr %p) {
|
|
%t = load i64, ptr %p
|
|
ret i64 %t
|
|
}
|