2011-11-01 07:58:51 +08:00
|
|
|
//===-- ModuleUtils.cpp - Functions to manipulate Modules -----------------===//
|
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2011-11-01 07:58:51 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This family of functions perform manipulations on Modules.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "llvm/Transforms/Utils/ModuleUtils.h"
|
2019-12-14 03:43:26 +08:00
|
|
|
#include "llvm/Analysis/TargetLibraryInfo.h"
|
2019-10-31 03:08:21 +08:00
|
|
|
#include "llvm/Analysis/VectorUtils.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/DerivedTypes.h"
|
|
|
|
#include "llvm/IR/Function.h"
|
|
|
|
#include "llvm/IR/IRBuilder.h"
|
|
|
|
#include "llvm/IR/Module.h"
|
2015-04-07 05:09:08 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2019-12-14 03:15:29 +08:00
|
|
|
using namespace llvm;
|
[VectorUtils] Introduce the Vector Function Database (VFDatabase).
This patch introduced the VFDatabase, the framework proposed in
http://lists.llvm.org/pipermail/llvm-dev/2019-June/133484.html. [*]
In this patch the VFDatabase is used to bridge the TargetLibraryInfo
(TLI) calls that were previously used to query for the availability of
vector counterparts of scalar functions.
The VFISAKind field `ISA` of VFShape have been moved into into VFInfo,
under the assumption that different vector ISAs may provide the same
vector signature. At the moment, the vectorizer accepts any of the
available ISAs as long as the signature provided by the VFDatabase
matches the one expected in the vectorization process. For example,
when targeting AVX or AVX2, which both have 256-bit registers, the IR
signature of the two vector functions associated to the two ISAs is
the same. The `getVectorizedFunction` method at the moment returns the
first available match. We will need to add more heuristics to the
search system to decide which of the available version (TLI, AVX,
AVX2, ...) the system should prefer, when multiple versions with the
same VFShape are present.
Some of the code in this patch is based on the work done by Sumedh
Arani in https://reviews.llvm.org/D66025.
[*] Notice that in the proposal the VFDatabase was called SVFS. The
name VFDatabase is more in line with LLVM recommendations for
naming classes and variables.
Differential Revision: https://reviews.llvm.org/D67572
2019-10-31 03:08:21 +08:00
|
|
|
|
2019-12-14 03:43:26 +08:00
|
|
|
#define DEBUG_TYPE "moduleutils"
|
|
|
|
|
2016-02-12 08:37:52 +08:00
|
|
|
static void appendToGlobalArray(const char *Array, Module &M, Function *F,
|
|
|
|
int Priority, Constant *Data) {
|
2011-11-01 07:58:51 +08:00
|
|
|
IRBuilder<> IRB(M.getContext());
|
|
|
|
FunctionType *FnTy = FunctionType::get(IRB.getVoidTy(), false);
|
|
|
|
|
|
|
|
// Get the current set of static global constructors and add the new ctor
|
|
|
|
// to the list.
|
|
|
|
SmallVector<Constant *, 16> CurrentCtors;
|
2019-05-15 10:35:32 +08:00
|
|
|
StructType *EltTy = StructType::get(
|
|
|
|
IRB.getInt32Ty(), PointerType::getUnqual(FnTy), IRB.getInt8PtrTy());
|
2014-05-17 04:39:27 +08:00
|
|
|
if (GlobalVariable *GVCtor = M.getNamedGlobal(Array)) {
|
2011-11-01 07:58:51 +08:00
|
|
|
if (Constant *Init = GVCtor->getInitializer()) {
|
|
|
|
unsigned n = Init->getNumOperands();
|
|
|
|
CurrentCtors.reserve(n + 1);
|
2019-05-15 10:35:32 +08:00
|
|
|
for (unsigned i = 0; i != n; ++i)
|
|
|
|
CurrentCtors.push_back(cast<Constant>(Init->getOperand(i)));
|
2011-11-01 07:58:51 +08:00
|
|
|
}
|
|
|
|
GVCtor->eraseFromParent();
|
|
|
|
}
|
|
|
|
|
2019-05-15 10:35:32 +08:00
|
|
|
// Build a 3 field global_ctor entry. We don't take a comdat key.
|
2014-05-17 04:39:27 +08:00
|
|
|
Constant *CSVals[3];
|
|
|
|
CSVals[0] = IRB.getInt32(Priority);
|
|
|
|
CSVals[1] = F;
|
2019-05-15 10:35:32 +08:00
|
|
|
CSVals[2] = Data ? ConstantExpr::getPointerCast(Data, IRB.getInt8PtrTy())
|
|
|
|
: Constant::getNullValue(IRB.getInt8PtrTy());
|
2014-05-17 04:39:27 +08:00
|
|
|
Constant *RuntimeCtorInit =
|
|
|
|
ConstantStruct::get(EltTy, makeArrayRef(CSVals, EltTy->getNumElements()));
|
|
|
|
|
2011-11-01 07:58:51 +08:00
|
|
|
CurrentCtors.push_back(RuntimeCtorInit);
|
|
|
|
|
|
|
|
// Create a new initializer.
|
2014-05-17 04:39:27 +08:00
|
|
|
ArrayType *AT = ArrayType::get(EltTy, CurrentCtors.size());
|
2011-11-01 07:58:51 +08:00
|
|
|
Constant *NewInit = ConstantArray::get(AT, CurrentCtors);
|
|
|
|
|
|
|
|
// Create the new global variable and replace all uses of
|
|
|
|
// the old global variable with the new one.
|
|
|
|
(void)new GlobalVariable(M, NewInit->getType(), false,
|
2011-12-16 05:59:03 +08:00
|
|
|
GlobalValue::AppendingLinkage, NewInit, Array);
|
|
|
|
}
|
|
|
|
|
2016-02-12 08:37:52 +08:00
|
|
|
void llvm::appendToGlobalCtors(Module &M, Function *F, int Priority, Constant *Data) {
|
|
|
|
appendToGlobalArray("llvm.global_ctors", M, F, Priority, Data);
|
2011-12-16 05:59:03 +08:00
|
|
|
}
|
|
|
|
|
2016-02-12 08:37:52 +08:00
|
|
|
void llvm::appendToGlobalDtors(Module &M, Function *F, int Priority, Constant *Data) {
|
|
|
|
appendToGlobalArray("llvm.global_dtors", M, F, Priority, Data);
|
2011-11-01 07:58:51 +08:00
|
|
|
}
|
2013-07-25 11:23:25 +08:00
|
|
|
|
2016-10-26 07:53:31 +08:00
|
|
|
static void appendToUsedList(Module &M, StringRef Name, ArrayRef<GlobalValue *> Values) {
|
|
|
|
GlobalVariable *GV = M.getGlobalVariable(Name);
|
|
|
|
SmallPtrSet<Constant *, 16> InitAsSet;
|
|
|
|
SmallVector<Constant *, 16> Init;
|
|
|
|
if (GV) {
|
2021-02-19 09:23:02 +08:00
|
|
|
if (GV->hasInitializer()) {
|
|
|
|
auto *CA = cast<ConstantArray>(GV->getInitializer());
|
|
|
|
for (auto &Op : CA->operands()) {
|
|
|
|
Constant *C = cast_or_null<Constant>(Op);
|
|
|
|
if (InitAsSet.insert(C).second)
|
|
|
|
Init.push_back(C);
|
|
|
|
}
|
2016-10-26 07:53:31 +08:00
|
|
|
}
|
|
|
|
GV->eraseFromParent();
|
|
|
|
}
|
|
|
|
|
|
|
|
Type *Int8PtrTy = llvm::Type::getInt8PtrTy(M.getContext());
|
|
|
|
for (auto *V : Values) {
|
|
|
|
Constant *C = ConstantExpr::getBitCast(V, Int8PtrTy);
|
|
|
|
if (InitAsSet.insert(C).second)
|
|
|
|
Init.push_back(C);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Init.empty())
|
|
|
|
return;
|
|
|
|
|
|
|
|
ArrayType *ATy = ArrayType::get(Int8PtrTy, Init.size());
|
|
|
|
GV = new llvm::GlobalVariable(M, ATy, false, GlobalValue::AppendingLinkage,
|
|
|
|
ConstantArray::get(ATy, Init), Name);
|
|
|
|
GV->setSection("llvm.metadata");
|
|
|
|
}
|
|
|
|
|
|
|
|
void llvm::appendToUsed(Module &M, ArrayRef<GlobalValue *> Values) {
|
|
|
|
appendToUsedList(M, "llvm.used", Values);
|
|
|
|
}
|
|
|
|
|
|
|
|
void llvm::appendToCompilerUsed(Module &M, ArrayRef<GlobalValue *> Values) {
|
|
|
|
appendToUsedList(M, "llvm.compiler.used", Values);
|
|
|
|
}
|
|
|
|
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
FunctionCallee
|
|
|
|
llvm::declareSanitizerInitFunction(Module &M, StringRef InitName,
|
|
|
|
ArrayRef<Type *> InitArgTypes) {
|
2017-04-07 03:55:09 +08:00
|
|
|
assert(!InitName.empty() && "Expected init function name");
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
return M.getOrInsertFunction(
|
2017-04-07 03:55:09 +08:00
|
|
|
InitName,
|
|
|
|
FunctionType::get(Type::getVoidTy(M.getContext()), InitArgTypes, false),
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
AttributeList());
|
2017-04-07 03:55:09 +08:00
|
|
|
}
|
|
|
|
|
2020-06-10 21:01:40 +08:00
|
|
|
Function *llvm::createSanitizerCtor(Module &M, StringRef CtorName) {
|
|
|
|
Function *Ctor = Function::Create(
|
|
|
|
FunctionType::get(Type::getVoidTy(M.getContext()), false),
|
|
|
|
GlobalValue::InternalLinkage, CtorName, &M);
|
|
|
|
BasicBlock *CtorBB = BasicBlock::Create(M.getContext(), "", Ctor);
|
|
|
|
ReturnInst::Create(M.getContext(), CtorBB);
|
|
|
|
return Ctor;
|
|
|
|
}
|
|
|
|
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
std::pair<Function *, FunctionCallee> llvm::createSanitizerCtorAndInitFunctions(
|
2015-05-07 02:48:22 +08:00
|
|
|
Module &M, StringRef CtorName, StringRef InitName,
|
2015-07-23 18:54:06 +08:00
|
|
|
ArrayRef<Type *> InitArgTypes, ArrayRef<Value *> InitArgs,
|
|
|
|
StringRef VersionCheckName) {
|
2015-05-07 02:48:22 +08:00
|
|
|
assert(!InitName.empty() && "Expected init function name");
|
2016-11-01 06:42:39 +08:00
|
|
|
assert(InitArgs.size() == InitArgTypes.size() &&
|
2015-05-07 02:48:22 +08:00
|
|
|
"Sanitizer's init function expects different number of arguments");
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
FunctionCallee InitFunction =
|
2017-04-07 03:55:09 +08:00
|
|
|
declareSanitizerInitFunction(M, InitName, InitArgTypes);
|
2020-06-10 21:01:40 +08:00
|
|
|
Function *Ctor = createSanitizerCtor(M, CtorName);
|
|
|
|
IRBuilder<> IRB(Ctor->getEntryBlock().getTerminator());
|
2015-05-07 02:48:22 +08:00
|
|
|
IRB.CreateCall(InitFunction, InitArgs);
|
2015-07-23 18:54:06 +08:00
|
|
|
if (!VersionCheckName.empty()) {
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
FunctionCallee VersionCheckFunction = M.getOrInsertFunction(
|
|
|
|
VersionCheckName, FunctionType::get(IRB.getVoidTy(), {}, false),
|
|
|
|
AttributeList());
|
2015-07-23 18:54:06 +08:00
|
|
|
IRB.CreateCall(VersionCheckFunction, {});
|
|
|
|
}
|
2015-05-07 02:48:22 +08:00
|
|
|
return std::make_pair(Ctor, InitFunction);
|
|
|
|
}
|
2016-12-27 07:43:27 +08:00
|
|
|
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
std::pair<Function *, FunctionCallee>
|
2019-01-16 17:28:01 +08:00
|
|
|
llvm::getOrCreateSanitizerCtorAndInitFunctions(
|
|
|
|
Module &M, StringRef CtorName, StringRef InitName,
|
|
|
|
ArrayRef<Type *> InitArgTypes, ArrayRef<Value *> InitArgs,
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
function_ref<void(Function *, FunctionCallee)> FunctionsCreatedCallback,
|
2019-01-16 17:28:01 +08:00
|
|
|
StringRef VersionCheckName) {
|
|
|
|
assert(!CtorName.empty() && "Expected ctor function name");
|
|
|
|
|
|
|
|
if (Function *Ctor = M.getFunction(CtorName))
|
|
|
|
// FIXME: Sink this logic into the module, similar to the handling of
|
|
|
|
// globals. This will make moving to a concurrent model much easier.
|
|
|
|
if (Ctor->arg_size() == 0 ||
|
|
|
|
Ctor->getReturnType() == Type::getVoidTy(M.getContext()))
|
|
|
|
return {Ctor, declareSanitizerInitFunction(M, InitName, InitArgTypes)};
|
|
|
|
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
Function *Ctor;
|
|
|
|
FunctionCallee InitFunction;
|
2019-01-16 17:28:01 +08:00
|
|
|
std::tie(Ctor, InitFunction) = llvm::createSanitizerCtorAndInitFunctions(
|
|
|
|
M, CtorName, InitName, InitArgTypes, InitArgs, VersionCheckName);
|
|
|
|
FunctionsCreatedCallback(Ctor, InitFunction);
|
|
|
|
return std::make_pair(Ctor, InitFunction);
|
|
|
|
}
|
|
|
|
|
[NewPM] Port Msan
Summary:
Keeping msan a function pass requires replacing the module level initialization:
That means, don't define a ctor function which calls __msan_init, instead just
declare the init function at the first access, and add that to the global ctors
list.
Changes:
- Pull the actual sanitizer and the wrapper pass apart.
- Add a newpm msan pass. The function pass inserts calls to runtime
library functions, for which it inserts declarations as necessary.
- Update tests.
Caveats:
- There is one test that I dropped, because it specifically tested the
definition of the ctor.
Reviewers: chandlerc, fedor.sergeev, leonardchan, vitalybuka
Subscribers: sdardis, nemanjai, javed.absar, hiraditya, kbarton, bollu, atanasyan, jsji
Differential Revision: https://reviews.llvm.org/D55647
llvm-svn: 350305
2019-01-03 21:42:44 +08:00
|
|
|
Function *llvm::getOrCreateInitFunction(Module &M, StringRef Name) {
|
|
|
|
assert(!Name.empty() && "Expected init function name");
|
|
|
|
if (Function *F = M.getFunction(Name)) {
|
|
|
|
if (F->arg_size() != 0 ||
|
|
|
|
F->getReturnType() != Type::getVoidTy(M.getContext())) {
|
|
|
|
std::string Err;
|
|
|
|
raw_string_ostream Stream(Err);
|
|
|
|
Stream << "Sanitizer interface function defined with wrong type: " << *F;
|
|
|
|
report_fatal_error(Err);
|
|
|
|
}
|
|
|
|
return F;
|
|
|
|
}
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
Function *F =
|
|
|
|
cast<Function>(M.getOrInsertFunction(Name, AttributeList(),
|
|
|
|
Type::getVoidTy(M.getContext()))
|
|
|
|
.getCallee());
|
[NewPM] Port Msan
Summary:
Keeping msan a function pass requires replacing the module level initialization:
That means, don't define a ctor function which calls __msan_init, instead just
declare the init function at the first access, and add that to the global ctors
list.
Changes:
- Pull the actual sanitizer and the wrapper pass apart.
- Add a newpm msan pass. The function pass inserts calls to runtime
library functions, for which it inserts declarations as necessary.
- Update tests.
Caveats:
- There is one test that I dropped, because it specifically tested the
definition of the ctor.
Reviewers: chandlerc, fedor.sergeev, leonardchan, vitalybuka
Subscribers: sdardis, nemanjai, javed.absar, hiraditya, kbarton, bollu, atanasyan, jsji
Differential Revision: https://reviews.llvm.org/D55647
llvm-svn: 350305
2019-01-03 21:42:44 +08:00
|
|
|
|
|
|
|
appendToGlobalCtors(M, F, 0);
|
|
|
|
|
|
|
|
return F;
|
|
|
|
}
|
|
|
|
|
2016-12-27 07:43:27 +08:00
|
|
|
void llvm::filterDeadComdatFunctions(
|
|
|
|
Module &M, SmallVectorImpl<Function *> &DeadComdatFunctions) {
|
|
|
|
// Build a map from the comdat to the number of entries in that comdat we
|
|
|
|
// think are dead. If this fully covers the comdat group, then the entire
|
|
|
|
// group is dead. If we find another entry in the comdat group though, we'll
|
|
|
|
// have to preserve the whole group.
|
|
|
|
SmallDenseMap<Comdat *, int, 16> ComdatEntriesCovered;
|
|
|
|
for (Function *F : DeadComdatFunctions) {
|
|
|
|
Comdat *C = F->getComdat();
|
|
|
|
assert(C && "Expected all input GVs to be in a comdat!");
|
|
|
|
ComdatEntriesCovered[C] += 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto CheckComdat = [&](Comdat &C) {
|
|
|
|
auto CI = ComdatEntriesCovered.find(&C);
|
|
|
|
if (CI == ComdatEntriesCovered.end())
|
|
|
|
return;
|
|
|
|
|
|
|
|
// If this could have been covered by a dead entry, just subtract one to
|
|
|
|
// account for it.
|
|
|
|
if (CI->second > 0) {
|
|
|
|
CI->second -= 1;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If we've already accounted for all the entries that were dead, the
|
|
|
|
// entire comdat is alive so remove it from the map.
|
|
|
|
ComdatEntriesCovered.erase(CI);
|
|
|
|
};
|
|
|
|
|
|
|
|
auto CheckAllComdats = [&] {
|
|
|
|
for (Function &F : M.functions())
|
|
|
|
if (Comdat *C = F.getComdat()) {
|
|
|
|
CheckComdat(*C);
|
|
|
|
if (ComdatEntriesCovered.empty())
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
for (GlobalVariable &GV : M.globals())
|
|
|
|
if (Comdat *C = GV.getComdat()) {
|
|
|
|
CheckComdat(*C);
|
|
|
|
if (ComdatEntriesCovered.empty())
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
for (GlobalAlias &GA : M.aliases())
|
|
|
|
if (Comdat *C = GA.getComdat()) {
|
|
|
|
CheckComdat(*C);
|
|
|
|
if (ComdatEntriesCovered.empty())
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
CheckAllComdats();
|
|
|
|
|
|
|
|
if (ComdatEntriesCovered.empty()) {
|
|
|
|
DeadComdatFunctions.clear();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Remove the entries that were not covering.
|
|
|
|
erase_if(DeadComdatFunctions, [&](GlobalValue *GV) {
|
|
|
|
return ComdatEntriesCovered.find(GV->getComdat()) ==
|
|
|
|
ComdatEntriesCovered.end();
|
|
|
|
});
|
|
|
|
}
|
2017-04-28 04:27:27 +08:00
|
|
|
|
|
|
|
std::string llvm::getUniqueModuleId(Module *M) {
|
|
|
|
MD5 Md5;
|
|
|
|
bool ExportsSymbols = false;
|
|
|
|
auto AddGlobal = [&](GlobalValue &GV) {
|
|
|
|
if (GV.isDeclaration() || GV.getName().startswith("llvm.") ||
|
2017-10-06 05:54:53 +08:00
|
|
|
!GV.hasExternalLinkage() || GV.hasComdat())
|
2017-04-28 04:27:27 +08:00
|
|
|
return;
|
|
|
|
ExportsSymbols = true;
|
|
|
|
Md5.update(GV.getName());
|
|
|
|
Md5.update(ArrayRef<uint8_t>{0});
|
|
|
|
};
|
|
|
|
|
|
|
|
for (auto &F : *M)
|
|
|
|
AddGlobal(F);
|
|
|
|
for (auto &GV : M->globals())
|
|
|
|
AddGlobal(GV);
|
|
|
|
for (auto &GA : M->aliases())
|
|
|
|
AddGlobal(GA);
|
|
|
|
for (auto &IF : M->ifuncs())
|
|
|
|
AddGlobal(IF);
|
|
|
|
|
|
|
|
if (!ExportsSymbols)
|
|
|
|
return "";
|
|
|
|
|
|
|
|
MD5::MD5Result R;
|
|
|
|
Md5.final(R);
|
|
|
|
|
|
|
|
SmallString<32> Str;
|
|
|
|
MD5::stringifyResult(R, Str);
|
|
|
|
return ("$" + Str).str();
|
|
|
|
}
|
2019-10-31 03:08:21 +08:00
|
|
|
|
|
|
|
void VFABI::setVectorVariantNames(
|
|
|
|
CallInst *CI, const SmallVector<std::string, 8> &VariantMappings) {
|
|
|
|
if (VariantMappings.empty())
|
|
|
|
return;
|
|
|
|
|
|
|
|
SmallString<256> Buffer;
|
|
|
|
llvm::raw_svector_ostream Out(Buffer);
|
|
|
|
for (const std::string &VariantMapping : VariantMappings)
|
|
|
|
Out << VariantMapping << ",";
|
|
|
|
// Get rid of the trailing ','.
|
|
|
|
assert(!Buffer.str().empty() && "Must have at least one char.");
|
|
|
|
Buffer.pop_back();
|
|
|
|
|
|
|
|
Module *M = CI->getModule();
|
|
|
|
#ifndef NDEBUG
|
|
|
|
for (const std::string &VariantMapping : VariantMappings) {
|
2019-12-14 03:43:26 +08:00
|
|
|
LLVM_DEBUG(dbgs() << "VFABI: adding mapping '" << VariantMapping << "'\n");
|
[llvm][VectorUtils] Tweak VFShape for scalable vector functions.
Summary:
This patch makes sure that the field VFShape.VF is greater than zero
when demangling the vector function name of scalable vector functions
encoded in the "vector-function-abi-variant" attribute.
This change is required to be able to provide instances of VFShape
that can be used to query the VFDatabase for the vectorization passes,
as such passes always require a positive value for the Vectorization Factor (VF)
needed by the vectorization process.
It is not possible to extract the value of VFShape.VF from the mangled
name of scalable vector functions, because it is encoded as
`x`. Therefore, the VFABI demangling function has been modified to
extract such information from the IR declaration of the vector
function, under the assumption that _all_ vectors in the signature of
the vector function have the same number of lanes. Such assumption is
valid because it is also assumed by the Vector Function ABI
specifications supported by the demangling function (x86, AArch64, and
LLVM internal one).
The unit tests that demangle scalable names have been modified by
adding the IR module that carries the declaration of the vector
function name being demangled.
In particular, the demangling function fails in the following cases:
1. When the declaration of the scalable vector function is not
present in the module.
2. When the value of VFSHape.VF is not greater than 0.
Reviewers: jdoerfert, sdesmalen, andwar
Reviewed By: jdoerfert
Subscribers: mgorny, kristof.beyls, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73286
2020-01-23 06:34:27 +08:00
|
|
|
Optional<VFInfo> VI = VFABI::tryDemangleForVFABI(VariantMapping, *M);
|
2019-12-14 03:43:26 +08:00
|
|
|
assert(VI.hasValue() && "Cannot add an invalid VFABI name.");
|
2019-10-31 03:08:21 +08:00
|
|
|
assert(M->getNamedValue(VI.getValue().VectorName) &&
|
|
|
|
"Cannot add variant to attribute: "
|
|
|
|
"vector function declaration is missing.");
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
CI->addAttribute(
|
|
|
|
AttributeList::FunctionIndex,
|
|
|
|
Attribute::get(M->getContext(), MappingsAttrName, Buffer.str()));
|
|
|
|
}
|