llvm-project/clang/test/CodeGen/split-lto-unit-input.cpp
Fangrui Song b2f7b5dbae [CodeGen] Support bitcode input containing multiple modules
When using -fsplit-lto-unit (explicitly specified or due to using
-fsanitize=cfi/-fwhole-program-vtables), the emitted LLVM IR contains a module
flag metadata `"EnableSplitLTOUnit"`. If a module contains both type metadata
and `"EnableSplitLTOUnit"`, `ThinLTOBitcodeWriter.cpp` will write two modules
into the bitcode file. Compiling the bitcode (not ThinLTO backend compilation)
will lead to an error due to `parseIR` requiring a single module.

```
% clang -flto=thin a.cc -c -o a.bc
% clang -c a.bc
% clang -fsplit-lto-unit -flto=thin a.cc -c -o a.bc
% clang -c a.bc
error: Expected a single module
1 error generated.
```

There are multiple ways to have just one module in a bitcode file
output: `-Xclang -fno-lto-unit`, not using features like `-fsanitize=cfi`,
using `-fsanitize=cfi` with `-fno-split-lto-unit`. I think whether a
bitcode input file contains 2 modules (internal implementation strategy)
should not be a criterion to require an additional driver option when
the user seek for a non-LTO compile action.

Let's place the extra module (if present) into CodeGenOptions::LinkBitcodeFiles
(originally for -cc1 -mlink-bitcode-file). Linker::linkModules will link the two
modules together. This patch makes the following commands work:

```
clang -S -emit-llvm a.bc
clang -S a.bc
clang -c a.bc
```

Reviewed By: ormris

Differential Revision: https://reviews.llvm.org/D154923
2023-07-21 20:05:35 -07:00

33 lines
1.0 KiB
C++

// REQUIRES: x86-registered-target
/// When the input is a -fsplit-lto-unit bitcode file, link the regular LTO file like -mlink-bitcode-file.
// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm-bc -flto=thin -flto-unit -fsplit-lto-unit %s -o %t.bc
// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-obj %t.bc -o %t.o
// RUN: llvm-nm %t.o | FileCheck %s
// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm %t.bc -o - | FileCheck %s --check-prefix=CHECK-IR
// CHECK: V _ZTI1A
// CHECK-NEXT: V _ZTI1B
// CHECK-NEXT: V _ZTS1A
// CHECK-NEXT: V _ZTS1B
// CHECK-NEXT: V _ZTV1A
// CHECK-NEXT: V _ZTV1B
// CHECK-IR-DAG: _ZTS1B = linkonce_odr constant
// CHECK-IR-DAG: _ZTS1A = linkonce_odr constant
// CHECK-IR-DAG: _ZTV1B = linkonce_odr unnamed_addr constant
// CHECK-IR-DAG: _ZTI1A = linkonce_odr constant
// CHECK-IR-DAG: _ZTI1B = linkonce_odr constant
// CHECK-IR-DAG: _ZTV1A = linkonce_odr unnamed_addr constant
struct A {
virtual int c(int i) = 0;
};
struct B : A {
virtual int c(int i) { return i; }
};
int use() {
return (new B)->c(0);
}