2009-01-02 15:01:27 +08:00
|
|
|
//===-- LLParser.h - Parser Class -------------------------------*- C++ -*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file defines the parser class for .ll files.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2014-08-14 00:26:38 +08:00
|
|
|
#ifndef LLVM_LIB_ASMPARSER_LLPARSER_H
|
|
|
|
#define LLVM_LIB_ASMPARSER_LLPARSER_H
|
2009-01-02 15:01:27 +08:00
|
|
|
|
|
|
|
#include "LLLexer.h"
|
2012-12-04 15:12:27 +08:00
|
|
|
#include "llvm/ADT/DenseMap.h"
|
|
|
|
#include "llvm/ADT/StringMap.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/Attributes.h"
|
|
|
|
#include "llvm/IR/Instructions.h"
|
|
|
|
#include "llvm/IR/Module.h"
|
|
|
|
#include "llvm/IR/Operator.h"
|
|
|
|
#include "llvm/IR/Type.h"
|
2014-03-04 19:17:44 +08:00
|
|
|
#include "llvm/IR/ValueHandle.h"
|
2009-12-30 05:43:58 +08:00
|
|
|
#include <map>
|
2009-01-02 15:01:27 +08:00
|
|
|
|
|
|
|
namespace llvm {
|
|
|
|
class Module;
|
|
|
|
class OpaqueType;
|
|
|
|
class Function;
|
|
|
|
class Value;
|
|
|
|
class BasicBlock;
|
|
|
|
class Instruction;
|
|
|
|
class Constant;
|
|
|
|
class GlobalValue;
|
2014-06-28 02:19:56 +08:00
|
|
|
class Comdat;
|
2009-04-04 15:22:01 +08:00
|
|
|
class MDString;
|
|
|
|
class MDNode;
|
2015-06-24 01:10:10 +08:00
|
|
|
struct SlotMapping;
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
class StructType;
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2009-10-28 11:39:23 +08:00
|
|
|
/// ValID - Represents a reference of a definition of some sort with no type.
|
|
|
|
/// There are several cases where we have to parse the value but where the
|
|
|
|
/// type can depend on later context. This may either be a numeric reference
|
|
|
|
/// or a symbolic (%var) reference. This is just a discriminated union.
|
2013-09-12 02:05:11 +08:00
|
|
|
struct ValID {
|
2009-10-28 11:39:23 +08:00
|
|
|
enum {
|
2015-11-12 05:57:16 +08:00
|
|
|
t_LocalID, t_GlobalID, // ID in UIntVal.
|
|
|
|
t_LocalName, t_GlobalName, // Name in StrVal.
|
|
|
|
t_APSInt, t_APFloat, // Value in APSIntVal/APFloatVal.
|
|
|
|
t_Null, t_Undef, t_Zero, t_None, // No value.
|
|
|
|
t_EmptyArray, // No value: []
|
|
|
|
t_Constant, // Value in ConstantVal.
|
|
|
|
t_InlineAsm, // Value in FTy/StrVal/StrVal2/UIntVal.
|
|
|
|
t_ConstantStruct, // Value in ConstantStructElts.
|
|
|
|
t_PackedConstantStruct // Value in ConstantStructElts.
|
2015-08-04 04:08:41 +08:00
|
|
|
} Kind = t_LocalID;
|
2012-11-16 06:34:00 +08:00
|
|
|
|
2009-10-28 11:39:23 +08:00
|
|
|
LLLexer::LocTy Loc;
|
|
|
|
unsigned UIntVal;
|
2015-09-04 00:18:32 +08:00
|
|
|
FunctionType *FTy = nullptr;
|
2009-10-28 11:39:23 +08:00
|
|
|
std::string StrVal, StrVal2;
|
|
|
|
APSInt APSIntVal;
|
2015-08-04 04:08:41 +08:00
|
|
|
APFloat APFloatVal{0.0};
|
2009-10-28 11:39:23 +08:00
|
|
|
Constant *ConstantVal;
|
2015-08-04 04:08:41 +08:00
|
|
|
std::unique_ptr<Constant *[]> ConstantStructElts;
|
2012-11-16 06:34:00 +08:00
|
|
|
|
2015-08-04 04:08:41 +08:00
|
|
|
ValID() = default;
|
2015-08-04 04:30:53 +08:00
|
|
|
ValID(const ValID &RHS)
|
2015-08-04 04:08:41 +08:00
|
|
|
: Kind(RHS.Kind), Loc(RHS.Loc), UIntVal(RHS.UIntVal), FTy(RHS.FTy),
|
2015-08-04 04:30:53 +08:00
|
|
|
StrVal(RHS.StrVal), StrVal2(RHS.StrVal2), APSIntVal(RHS.APSIntVal),
|
|
|
|
APFloatVal(RHS.APFloatVal), ConstantVal(RHS.ConstantVal) {
|
|
|
|
assert(!RHS.ConstantStructElts);
|
|
|
|
}
|
2012-11-16 06:34:00 +08:00
|
|
|
|
2009-10-28 11:39:23 +08:00
|
|
|
bool operator<(const ValID &RHS) const {
|
|
|
|
if (Kind == t_LocalID || Kind == t_GlobalID)
|
|
|
|
return UIntVal < RHS.UIntVal;
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
assert((Kind == t_LocalName || Kind == t_GlobalName ||
|
2012-11-16 06:34:00 +08:00
|
|
|
Kind == t_ConstantStruct || Kind == t_PackedConstantStruct) &&
|
2009-10-28 11:39:23 +08:00
|
|
|
"Ordering not defined for this ValID kind yet");
|
|
|
|
return StrVal < RHS.StrVal;
|
|
|
|
}
|
|
|
|
};
|
2012-11-16 06:34:00 +08:00
|
|
|
|
2013-09-12 02:05:11 +08:00
|
|
|
class LLParser {
|
2009-01-02 15:01:27 +08:00
|
|
|
public:
|
|
|
|
typedef LLLexer::LocTy LocTy;
|
|
|
|
private:
|
2010-04-07 12:08:57 +08:00
|
|
|
LLVMContext &Context;
|
2009-01-02 15:01:27 +08:00
|
|
|
LLLexer Lex;
|
|
|
|
Module *M;
|
2015-06-24 01:10:10 +08:00
|
|
|
SlotMapping *Slots;
|
2012-11-16 06:34:00 +08:00
|
|
|
|
2010-04-01 13:14:45 +08:00
|
|
|
// Instruction metadata resolution. Each instruction can have a list of
|
|
|
|
// MDRef info associated with them.
|
2010-08-24 22:31:06 +08:00
|
|
|
//
|
|
|
|
// The simpler approach of just creating temporary MDNodes and then calling
|
|
|
|
// RAUW on them when the definition is processed doesn't work because some
|
|
|
|
// instruction metadata kinds, such as dbg, get stored in the IR in an
|
|
|
|
// "optimized" format which doesn't participate in the normal value use
|
|
|
|
// lists. This means that RAUW doesn't work, even on temporary MDNodes
|
|
|
|
// which otherwise support RAUW. Instead, we defer resolving MDNode
|
|
|
|
// references until the definitions have been processed.
|
2010-04-01 13:14:45 +08:00
|
|
|
struct MDRef {
|
|
|
|
SMLoc Loc;
|
|
|
|
unsigned MDKind, MDSlot;
|
|
|
|
};
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2013-09-28 08:22:27 +08:00
|
|
|
SmallVector<Instruction*, 64> InstsWithTBAATag;
|
|
|
|
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
// Type resolution handling data structures. The location is set when we
|
|
|
|
// have processed a use of the type but not a definition yet.
|
|
|
|
StringMap<std::pair<Type*, LocTy> > NamedTypes;
|
2015-02-11 15:43:56 +08:00
|
|
|
std::map<unsigned, std::pair<Type*, LocTy> > NumberedTypes;
|
2012-11-16 06:34:00 +08:00
|
|
|
|
2015-02-11 15:43:56 +08:00
|
|
|
std::map<unsigned, TrackingMDNodeRef> NumberedMetadata;
|
2015-01-20 05:30:18 +08:00
|
|
|
std::map<unsigned, std::pair<TempMDTuple, LocTy>> ForwardRefMDNodes;
|
2009-01-02 15:01:27 +08:00
|
|
|
|
|
|
|
// Global Value reference information.
|
|
|
|
std::map<std::string, std::pair<GlobalValue*, LocTy> > ForwardRefVals;
|
|
|
|
std::map<unsigned, std::pair<GlobalValue*, LocTy> > ForwardRefValIDs;
|
|
|
|
std::vector<GlobalValue*> NumberedVals;
|
2012-11-16 06:34:00 +08:00
|
|
|
|
2014-06-28 02:19:56 +08:00
|
|
|
// Comdat forward reference information.
|
|
|
|
std::map<std::string, LocTy> ForwardRefComdats;
|
|
|
|
|
2009-10-28 11:39:23 +08:00
|
|
|
// References to blockaddress. The key is the function ValID, the value is
|
|
|
|
// a list of references to blocks in that function.
|
LLParser: Handle BlockAddresses on-the-fly
Previously all `blockaddress()` constants were treated as forward
references. They were resolved twice: once at the end of the function
in question, and again at the end of the module. Furthermore, if the
same blockaddress was referenced N times, the parser created N distinct
`GlobalVariable`s (one for each reference).
Instead, resolve all block addresses at the beginning of the function,
creating the standard `BasicBlock` forward references used for all other
basic block references. After the function, all references can be
resolved immediately. To check for the condition of parsing block
addresses from within the same function, I created a reference to the
current per-function-state in `BlockAddressPFS`.
Also, create only one forward-reference per basic block. Because
forward references to block addresses are rare, the data structure here
shouldn't matter. If somehow it does someday, this can be pretty easily
changed to a `DenseMap<std::pair<ValID, ValID>, GV>`.
This is part of PR20515.
llvm-svn: 215952
2014-08-19 08:13:19 +08:00
|
|
|
std::map<ValID, std::map<ValID, GlobalValue *>> ForwardRefBlockAddresses;
|
|
|
|
class PerFunctionState;
|
|
|
|
/// Reference to per-function state to allow basic blocks to be
|
|
|
|
/// forward-referenced by blockaddress instructions within the same
|
|
|
|
/// function.
|
|
|
|
PerFunctionState *BlockAddressPFS;
|
2012-11-16 06:34:00 +08:00
|
|
|
|
2013-02-06 14:52:58 +08:00
|
|
|
// Attribute builder reference information.
|
2013-02-08 14:32:06 +08:00
|
|
|
std::map<Value*, std::vector<unsigned> > ForwardRefAttrGroups;
|
|
|
|
std::map<unsigned, AttrBuilder> NumberedAttrBuilders;
|
2013-02-06 14:52:58 +08:00
|
|
|
|
2009-01-02 15:01:27 +08:00
|
|
|
public:
|
2015-06-24 01:10:10 +08:00
|
|
|
LLParser(StringRef F, SourceMgr &SM, SMDiagnostic &Err, Module *M,
|
|
|
|
SlotMapping *Slots = nullptr)
|
|
|
|
: Context(M->getContext()), Lex(F, SM, Err, M->getContext()), M(M),
|
|
|
|
Slots(Slots), BlockAddressPFS(nullptr) {}
|
2009-01-05 04:44:11 +08:00
|
|
|
bool Run();
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2015-08-22 05:32:39 +08:00
|
|
|
bool parseStandaloneConstantValue(Constant *&C, const SlotMapping *Slots);
|
2015-07-18 06:07:03 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
LLVMContext &getContext() { return Context; }
|
2009-07-03 01:04:01 +08:00
|
|
|
|
2009-01-02 15:01:27 +08:00
|
|
|
private:
|
|
|
|
|
2010-09-28 01:42:11 +08:00
|
|
|
bool Error(LocTy L, const Twine &Msg) const {
|
2009-01-02 15:01:27 +08:00
|
|
|
return Lex.Error(L, Msg);
|
|
|
|
}
|
2010-09-28 01:42:11 +08:00
|
|
|
bool TokError(const Twine &Msg) const {
|
2009-01-02 15:01:27 +08:00
|
|
|
return Error(Lex.getLoc(), Msg);
|
|
|
|
}
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2015-08-22 05:32:39 +08:00
|
|
|
/// Restore the internal name and slot mappings using the mappings that
|
|
|
|
/// were created at an earlier parsing stage.
|
|
|
|
void restoreParsingState(const SlotMapping *Slots);
|
|
|
|
|
2009-01-02 15:01:27 +08:00
|
|
|
/// GetGlobalVal - Get a value with the specified name or ID, creating a
|
|
|
|
/// forward reference record if needed. This can return null if the value
|
|
|
|
/// exists but does not have the right type.
|
2011-07-18 12:54:35 +08:00
|
|
|
GlobalValue *GetGlobalVal(const std::string &N, Type *Ty, LocTy Loc);
|
|
|
|
GlobalValue *GetGlobalVal(unsigned ID, Type *Ty, LocTy Loc);
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2014-06-28 02:19:56 +08:00
|
|
|
/// Get a Comdat with the specified name, creating a forward reference
|
|
|
|
/// record if needed.
|
|
|
|
Comdat *getComdat(const std::string &N, LocTy Loc);
|
|
|
|
|
2009-01-02 15:01:27 +08:00
|
|
|
// Helper Routines.
|
|
|
|
bool ParseToken(lltok::Kind T, const char *ErrMsg);
|
2009-01-02 16:05:26 +08:00
|
|
|
bool EatIfPresent(lltok::Kind T) {
|
|
|
|
if (Lex.getKind() != T) return false;
|
|
|
|
Lex.Lex();
|
|
|
|
return true;
|
|
|
|
}
|
2012-11-27 08:42:44 +08:00
|
|
|
|
|
|
|
FastMathFlags EatFastMathFlagsIfPresent() {
|
|
|
|
FastMathFlags FMF;
|
|
|
|
while (true)
|
|
|
|
switch (Lex.getKind()) {
|
2012-12-10 05:12:04 +08:00
|
|
|
case lltok::kw_fast: FMF.setUnsafeAlgebra(); Lex.Lex(); continue;
|
|
|
|
case lltok::kw_nnan: FMF.setNoNaNs(); Lex.Lex(); continue;
|
|
|
|
case lltok::kw_ninf: FMF.setNoInfs(); Lex.Lex(); continue;
|
|
|
|
case lltok::kw_nsz: FMF.setNoSignedZeros(); Lex.Lex(); continue;
|
|
|
|
case lltok::kw_arcp: FMF.setAllowReciprocal(); Lex.Lex(); continue;
|
2012-11-27 08:42:44 +08:00
|
|
|
default: return FMF;
|
|
|
|
}
|
|
|
|
return FMF;
|
|
|
|
}
|
|
|
|
|
2014-04-16 12:21:27 +08:00
|
|
|
bool ParseOptionalToken(lltok::Kind T, bool &Present,
|
|
|
|
LocTy *Loc = nullptr) {
|
2009-01-02 15:01:27 +08:00
|
|
|
if (Lex.getKind() != T) {
|
|
|
|
Present = false;
|
|
|
|
} else {
|
2011-01-13 09:30:30 +08:00
|
|
|
if (Loc)
|
|
|
|
*Loc = Lex.getLoc();
|
2009-01-02 15:01:27 +08:00
|
|
|
Lex.Lex();
|
|
|
|
Present = true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
2009-01-02 16:05:26 +08:00
|
|
|
bool ParseStringConstant(std::string &Result);
|
|
|
|
bool ParseUInt32(unsigned &Val);
|
|
|
|
bool ParseUInt32(unsigned &Val, LocTy &Loc) {
|
2009-01-02 15:01:27 +08:00
|
|
|
Loc = Lex.getLoc();
|
2009-01-02 16:05:26 +08:00
|
|
|
return ParseUInt32(Val);
|
2009-01-02 15:01:27 +08:00
|
|
|
}
|
2014-07-18 23:51:28 +08:00
|
|
|
bool ParseUInt64(uint64_t &Val);
|
|
|
|
bool ParseUInt64(uint64_t &Val, LocTy &Loc) {
|
|
|
|
Loc = Lex.getLoc();
|
|
|
|
return ParseUInt64(Val);
|
|
|
|
}
|
2012-06-23 19:37:03 +08:00
|
|
|
|
2015-08-03 22:31:49 +08:00
|
|
|
bool ParseStringAttribute(AttrBuilder &B);
|
|
|
|
|
2012-06-23 19:37:03 +08:00
|
|
|
bool ParseTLSModel(GlobalVariable::ThreadLocalMode &TLM);
|
|
|
|
bool ParseOptionalThreadLocal(GlobalVariable::ThreadLocalMode &TLM);
|
2014-06-06 09:20:28 +08:00
|
|
|
bool parseOptionalUnnamedAddr(bool &UnnamedAddr) {
|
|
|
|
return ParseOptionalToken(lltok::kw_unnamed_addr, UnnamedAddr);
|
|
|
|
}
|
2009-01-02 15:01:27 +08:00
|
|
|
bool ParseOptionalAddrSpace(unsigned &AddrSpace);
|
2012-12-05 07:40:58 +08:00
|
|
|
bool ParseOptionalParamAttrs(AttrBuilder &B);
|
|
|
|
bool ParseOptionalReturnAttrs(AttrBuilder &B);
|
2009-01-02 15:01:27 +08:00
|
|
|
bool ParseOptionalLinkage(unsigned &Linkage, bool &HasLinkage);
|
|
|
|
bool ParseOptionalLinkage(unsigned &Linkage) {
|
|
|
|
bool HasLinkage; return ParseOptionalLinkage(Linkage, HasLinkage);
|
|
|
|
}
|
|
|
|
bool ParseOptionalVisibility(unsigned &Visibility);
|
2014-01-14 23:22:47 +08:00
|
|
|
bool ParseOptionalDLLStorageClass(unsigned &DLLStorageClass);
|
2014-09-11 02:00:17 +08:00
|
|
|
bool ParseOptionalCallingConv(unsigned &CC);
|
2009-01-02 15:01:27 +08:00
|
|
|
bool ParseOptionalAlignment(unsigned &Alignment);
|
2015-04-17 04:29:50 +08:00
|
|
|
bool ParseOptionalDerefAttrBytes(lltok::Kind AttrKind, uint64_t &Bytes);
|
2011-07-26 07:16:38 +08:00
|
|
|
bool ParseScopeAndOrdering(bool isAtomic, SynchronizationScope &Scope,
|
|
|
|
AtomicOrdering &Ordering);
|
2014-03-11 18:48:52 +08:00
|
|
|
bool ParseOrdering(AtomicOrdering &Ordering);
|
2010-02-12 08:31:15 +08:00
|
|
|
bool ParseOptionalStackAlignment(unsigned &Alignment);
|
2009-12-30 13:44:30 +08:00
|
|
|
bool ParseOptionalCommaAlign(unsigned &Alignment, bool &AteExtraComma);
|
2014-01-18 07:58:17 +08:00
|
|
|
bool ParseOptionalCommaInAlloca(bool &IsInAlloca);
|
2009-12-30 13:14:00 +08:00
|
|
|
bool ParseIndexList(SmallVectorImpl<unsigned> &Indices,bool &AteExtraComma);
|
|
|
|
bool ParseIndexList(SmallVectorImpl<unsigned> &Indices) {
|
|
|
|
bool AteExtraComma;
|
|
|
|
if (ParseIndexList(Indices, AteExtraComma)) return true;
|
|
|
|
if (AteExtraComma)
|
|
|
|
return TokError("expected index");
|
|
|
|
return false;
|
|
|
|
}
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2009-01-02 15:01:27 +08:00
|
|
|
// Top-Level Entities
|
|
|
|
bool ParseTopLevelEntities();
|
|
|
|
bool ValidateEndOfModule();
|
|
|
|
bool ParseTargetDefinition();
|
|
|
|
bool ParseModuleAsm();
|
2012-11-28 16:41:48 +08:00
|
|
|
bool ParseDepLibs(); // FIXME: Remove in 4.0.
|
2009-01-02 15:01:27 +08:00
|
|
|
bool ParseUnnamedType();
|
|
|
|
bool ParseNamedType();
|
|
|
|
bool ParseDeclare();
|
|
|
|
bool ParseDefine();
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2009-01-02 15:01:27 +08:00
|
|
|
bool ParseGlobalType(bool &IsConstant);
|
2009-08-13 07:32:33 +08:00
|
|
|
bool ParseUnnamedGlobal();
|
2009-01-02 15:01:27 +08:00
|
|
|
bool ParseNamedGlobal();
|
|
|
|
bool ParseGlobal(const std::string &Name, LocTy Loc, unsigned Linkage,
|
2014-01-14 23:22:47 +08:00
|
|
|
bool HasLinkage, unsigned Visibility,
|
2014-05-29 02:15:43 +08:00
|
|
|
unsigned DLLStorageClass,
|
2014-06-06 09:20:28 +08:00
|
|
|
GlobalVariable::ThreadLocalMode TLM, bool UnnamedAddr);
|
2014-07-31 06:51:54 +08:00
|
|
|
bool ParseAlias(const std::string &Name, LocTy Loc, unsigned Linkage,
|
|
|
|
unsigned Visibility, unsigned DLLStorageClass,
|
2014-06-06 09:20:28 +08:00
|
|
|
GlobalVariable::ThreadLocalMode TLM, bool UnnamedAddr);
|
2014-06-28 02:19:56 +08:00
|
|
|
bool parseComdat();
|
2009-07-02 03:21:12 +08:00
|
|
|
bool ParseStandaloneMetadata();
|
2009-07-29 08:34:02 +08:00
|
|
|
bool ParseNamedMetadata();
|
2009-12-30 05:53:55 +08:00
|
|
|
bool ParseMDString(MDString *&Result);
|
2009-12-30 12:15:23 +08:00
|
|
|
bool ParseMDNodeID(MDNode *&Result);
|
2013-02-06 14:52:58 +08:00
|
|
|
bool ParseUnnamedAttrGrp();
|
2013-02-08 14:32:06 +08:00
|
|
|
bool ParseFnAttributeValuePairs(AttrBuilder &B,
|
|
|
|
std::vector<unsigned> &FwdRefAttrGrps,
|
2013-06-27 08:25:01 +08:00
|
|
|
bool inAttrGrp, LocTy &BuiltinLoc);
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2009-01-02 15:01:27 +08:00
|
|
|
// Type Parsing.
|
IR: Make metadata typeless in assembly
Now that `Metadata` is typeless, reflect that in the assembly. These
are the matching assembly changes for the metadata/value split in
r223802.
- Only use the `metadata` type when referencing metadata from a call
intrinsic -- i.e., only when it's used as a `Value`.
- Stop pretending that `ValueAsMetadata` is wrapped in an `MDNode`
when referencing it from call intrinsics.
So, assembly like this:
define @foo(i32 %v) {
call void @llvm.foo(metadata !{i32 %v}, metadata !0)
call void @llvm.foo(metadata !{i32 7}, metadata !0)
call void @llvm.foo(metadata !1, metadata !0)
call void @llvm.foo(metadata !3, metadata !0)
call void @llvm.foo(metadata !{metadata !3}, metadata !0)
ret void, !bar !2
}
!0 = metadata !{metadata !2}
!1 = metadata !{i32* @global}
!2 = metadata !{metadata !3}
!3 = metadata !{}
turns into this:
define @foo(i32 %v) {
call void @llvm.foo(metadata i32 %v, metadata !0)
call void @llvm.foo(metadata i32 7, metadata !0)
call void @llvm.foo(metadata i32* @global, metadata !0)
call void @llvm.foo(metadata !3, metadata !0)
call void @llvm.foo(metadata !{!3}, metadata !0)
ret void, !bar !2
}
!0 = !{!2}
!1 = !{i32* @global}
!2 = !{!3}
!3 = !{}
I wrote an upgrade script that handled almost all of the tests in llvm
and many of the tests in cfe (even handling many `CHECK` lines). I've
attached it (or will attach it in a moment if you're speedy) to PR21532
to help everyone update their out-of-tree testcases.
This is part of PR21532.
llvm-svn: 224257
2014-12-16 03:07:53 +08:00
|
|
|
bool ParseType(Type *&Result, const Twine &Msg, bool AllowVoid = false);
|
|
|
|
bool ParseType(Type *&Result, bool AllowVoid = false) {
|
|
|
|
return ParseType(Result, "expected type", AllowVoid);
|
|
|
|
}
|
|
|
|
bool ParseType(Type *&Result, const Twine &Msg, LocTy &Loc,
|
|
|
|
bool AllowVoid = false) {
|
|
|
|
Loc = Lex.getLoc();
|
|
|
|
return ParseType(Result, Msg, AllowVoid);
|
|
|
|
}
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
bool ParseType(Type *&Result, LocTy &Loc, bool AllowVoid = false) {
|
2009-01-02 15:01:27 +08:00
|
|
|
Loc = Lex.getLoc();
|
2009-03-09 12:49:14 +08:00
|
|
|
return ParseType(Result, AllowVoid);
|
2009-01-02 15:01:27 +08:00
|
|
|
}
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
bool ParseAnonStructType(Type *&Result, bool Packed);
|
|
|
|
bool ParseStructBody(SmallVectorImpl<Type*> &Body);
|
|
|
|
bool ParseStructDefinition(SMLoc TypeLoc, StringRef Name,
|
|
|
|
std::pair<Type*, LocTy> &Entry,
|
|
|
|
Type *&ResultTy);
|
|
|
|
|
|
|
|
bool ParseArrayVectorType(Type *&Result, bool isVector);
|
|
|
|
bool ParseFunctionType(Type *&Result);
|
2009-01-02 15:01:27 +08:00
|
|
|
|
|
|
|
// Function Semantic Analysis.
|
|
|
|
class PerFunctionState {
|
|
|
|
LLParser &P;
|
|
|
|
Function &F;
|
|
|
|
std::map<std::string, std::pair<Value*, LocTy> > ForwardRefVals;
|
|
|
|
std::map<unsigned, std::pair<Value*, LocTy> > ForwardRefValIDs;
|
|
|
|
std::vector<Value*> NumberedVals;
|
2012-11-16 06:34:00 +08:00
|
|
|
|
2009-10-28 11:39:23 +08:00
|
|
|
/// FunctionNumber - If this is an unnamed function, this is the slot
|
|
|
|
/// number of it, otherwise it is -1.
|
|
|
|
int FunctionNumber;
|
2009-01-02 15:01:27 +08:00
|
|
|
public:
|
2009-10-28 11:39:23 +08:00
|
|
|
PerFunctionState(LLParser &p, Function &f, int FunctionNumber);
|
2009-01-02 15:01:27 +08:00
|
|
|
~PerFunctionState();
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2009-01-02 15:01:27 +08:00
|
|
|
Function &getFunction() const { return F; }
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2009-10-28 11:39:23 +08:00
|
|
|
bool FinishFunction();
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2009-01-02 15:01:27 +08:00
|
|
|
/// GetVal - Get a value with the specified name or ID, creating a
|
|
|
|
/// forward reference record if needed. This can return null if the value
|
|
|
|
/// exists but does not have the right type.
|
[IR] Reformulate LLVM's EH funclet IR
While we have successfully implemented a funclet-oriented EH scheme on
top of LLVM IR, our scheme has some notable deficiencies:
- catchendpad and cleanupendpad are necessary in the current design
but they are difficult to explain to others, even to seasoned LLVM
experts.
- catchendpad and cleanupendpad are optimization barriers. They cannot
be split and force all potentially throwing call-sites to be invokes.
This has a noticable effect on the quality of our code generation.
- catchpad, while similar in some aspects to invoke, is fairly awkward.
It is unsplittable, starts a funclet, and has control flow to other
funclets.
- The nesting relationship between funclets is currently a property of
control flow edges. Because of this, we are forced to carefully
analyze the flow graph to see if there might potentially exist illegal
nesting among funclets. While we have logic to clone funclets when
they are illegally nested, it would be nicer if we had a
representation which forbade them upfront.
Let's clean this up a bit by doing the following:
- Instead, make catchpad more like cleanuppad and landingpad: no control
flow, just a bunch of simple operands; catchpad would be splittable.
- Introduce catchswitch, a control flow instruction designed to model
the constraints of funclet oriented EH.
- Make funclet scoping explicit by having funclet instructions consume
the token produced by the funclet which contains them.
- Remove catchendpad and cleanupendpad. Their presence can be inferred
implicitly using coloring information.
N.B. The state numbering code for the CLR has been updated but the
veracity of it's output cannot be spoken for. An expert should take a
look to make sure the results are reasonable.
Reviewers: rnk, JosephTremoulet, andrew.w.kaylor
Differential Revision: http://reviews.llvm.org/D15139
llvm-svn: 255422
2015-12-12 13:38:55 +08:00
|
|
|
Value *GetVal(const std::string &Name, Type *Ty, LocTy Loc);
|
|
|
|
Value *GetVal(unsigned ID, Type *Ty, LocTy Loc);
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2009-01-02 15:01:27 +08:00
|
|
|
/// SetInstName - After an instruction is parsed and inserted into its
|
|
|
|
/// basic block, this installs its name.
|
|
|
|
bool SetInstName(int NameID, const std::string &NameStr, LocTy NameLoc,
|
|
|
|
Instruction *Inst);
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2009-01-02 15:01:27 +08:00
|
|
|
/// GetBB - Get a basic block with the specified name or ID, creating a
|
|
|
|
/// forward reference record if needed. This can return null if the value
|
|
|
|
/// is not a BasicBlock.
|
|
|
|
BasicBlock *GetBB(const std::string &Name, LocTy Loc);
|
|
|
|
BasicBlock *GetBB(unsigned ID, LocTy Loc);
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2009-01-02 15:01:27 +08:00
|
|
|
/// DefineBB - Define the specified basic block, which is either named or
|
|
|
|
/// unnamed. If there is an error, this returns null otherwise it returns
|
|
|
|
/// the block being defined.
|
|
|
|
BasicBlock *DefineBB(const std::string &Name, LocTy Loc);
|
LLParser: Handle BlockAddresses on-the-fly
Previously all `blockaddress()` constants were treated as forward
references. They were resolved twice: once at the end of the function
in question, and again at the end of the module. Furthermore, if the
same blockaddress was referenced N times, the parser created N distinct
`GlobalVariable`s (one for each reference).
Instead, resolve all block addresses at the beginning of the function,
creating the standard `BasicBlock` forward references used for all other
basic block references. After the function, all references can be
resolved immediately. To check for the condition of parsing block
addresses from within the same function, I created a reference to the
current per-function-state in `BlockAddressPFS`.
Also, create only one forward-reference per basic block. Because
forward references to block addresses are rare, the data structure here
shouldn't matter. If somehow it does someday, this can be pretty easily
changed to a `DenseMap<std::pair<ValID, ValID>, GV>`.
This is part of PR20515.
llvm-svn: 215952
2014-08-19 08:13:19 +08:00
|
|
|
|
|
|
|
bool resolveForwardRefBlockAddresses();
|
2009-01-02 15:01:27 +08:00
|
|
|
};
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2011-07-18 12:54:35 +08:00
|
|
|
bool ConvertValIDToValue(Type *Ty, ValID &ID, Value *&V,
|
[IR] Reformulate LLVM's EH funclet IR
While we have successfully implemented a funclet-oriented EH scheme on
top of LLVM IR, our scheme has some notable deficiencies:
- catchendpad and cleanupendpad are necessary in the current design
but they are difficult to explain to others, even to seasoned LLVM
experts.
- catchendpad and cleanupendpad are optimization barriers. They cannot
be split and force all potentially throwing call-sites to be invokes.
This has a noticable effect on the quality of our code generation.
- catchpad, while similar in some aspects to invoke, is fairly awkward.
It is unsplittable, starts a funclet, and has control flow to other
funclets.
- The nesting relationship between funclets is currently a property of
control flow edges. Because of this, we are forced to carefully
analyze the flow graph to see if there might potentially exist illegal
nesting among funclets. While we have logic to clone funclets when
they are illegally nested, it would be nicer if we had a
representation which forbade them upfront.
Let's clean this up a bit by doing the following:
- Instead, make catchpad more like cleanuppad and landingpad: no control
flow, just a bunch of simple operands; catchpad would be splittable.
- Introduce catchswitch, a control flow instruction designed to model
the constraints of funclet oriented EH.
- Make funclet scoping explicit by having funclet instructions consume
the token produced by the funclet which contains them.
- Remove catchendpad and cleanupendpad. Their presence can be inferred
implicitly using coloring information.
N.B. The state numbering code for the CLR has been updated but the
veracity of it's output cannot be spoken for. An expert should take a
look to make sure the results are reasonable.
Reviewers: rnk, JosephTremoulet, andrew.w.kaylor
Differential Revision: http://reviews.llvm.org/D15139
llvm-svn: 255422
2015-12-12 13:38:55 +08:00
|
|
|
PerFunctionState *PFS);
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2015-07-18 06:07:03 +08:00
|
|
|
bool parseConstantValue(Type *Ty, Constant *&C);
|
[IR] Reformulate LLVM's EH funclet IR
While we have successfully implemented a funclet-oriented EH scheme on
top of LLVM IR, our scheme has some notable deficiencies:
- catchendpad and cleanupendpad are necessary in the current design
but they are difficult to explain to others, even to seasoned LLVM
experts.
- catchendpad and cleanupendpad are optimization barriers. They cannot
be split and force all potentially throwing call-sites to be invokes.
This has a noticable effect on the quality of our code generation.
- catchpad, while similar in some aspects to invoke, is fairly awkward.
It is unsplittable, starts a funclet, and has control flow to other
funclets.
- The nesting relationship between funclets is currently a property of
control flow edges. Because of this, we are forced to carefully
analyze the flow graph to see if there might potentially exist illegal
nesting among funclets. While we have logic to clone funclets when
they are illegally nested, it would be nicer if we had a
representation which forbade them upfront.
Let's clean this up a bit by doing the following:
- Instead, make catchpad more like cleanuppad and landingpad: no control
flow, just a bunch of simple operands; catchpad would be splittable.
- Introduce catchswitch, a control flow instruction designed to model
the constraints of funclet oriented EH.
- Make funclet scoping explicit by having funclet instructions consume
the token produced by the funclet which contains them.
- Remove catchendpad and cleanupendpad. Their presence can be inferred
implicitly using coloring information.
N.B. The state numbering code for the CLR has been updated but the
veracity of it's output cannot be spoken for. An expert should take a
look to make sure the results are reasonable.
Reviewers: rnk, JosephTremoulet, andrew.w.kaylor
Differential Revision: http://reviews.llvm.org/D15139
llvm-svn: 255422
2015-12-12 13:38:55 +08:00
|
|
|
bool ParseValue(Type *Ty, Value *&V, PerFunctionState *PFS);
|
|
|
|
bool ParseValue(Type *Ty, Value *&V, PerFunctionState &PFS) {
|
|
|
|
return ParseValue(Ty, V, &PFS);
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
}
|
[IR] Reformulate LLVM's EH funclet IR
While we have successfully implemented a funclet-oriented EH scheme on
top of LLVM IR, our scheme has some notable deficiencies:
- catchendpad and cleanupendpad are necessary in the current design
but they are difficult to explain to others, even to seasoned LLVM
experts.
- catchendpad and cleanupendpad are optimization barriers. They cannot
be split and force all potentially throwing call-sites to be invokes.
This has a noticable effect on the quality of our code generation.
- catchpad, while similar in some aspects to invoke, is fairly awkward.
It is unsplittable, starts a funclet, and has control flow to other
funclets.
- The nesting relationship between funclets is currently a property of
control flow edges. Because of this, we are forced to carefully
analyze the flow graph to see if there might potentially exist illegal
nesting among funclets. While we have logic to clone funclets when
they are illegally nested, it would be nicer if we had a
representation which forbade them upfront.
Let's clean this up a bit by doing the following:
- Instead, make catchpad more like cleanuppad and landingpad: no control
flow, just a bunch of simple operands; catchpad would be splittable.
- Introduce catchswitch, a control flow instruction designed to model
the constraints of funclet oriented EH.
- Make funclet scoping explicit by having funclet instructions consume
the token produced by the funclet which contains them.
- Remove catchendpad and cleanupendpad. Their presence can be inferred
implicitly using coloring information.
N.B. The state numbering code for the CLR has been updated but the
veracity of it's output cannot be spoken for. An expert should take a
look to make sure the results are reasonable.
Reviewers: rnk, JosephTremoulet, andrew.w.kaylor
Differential Revision: http://reviews.llvm.org/D15139
llvm-svn: 255422
2015-12-12 13:38:55 +08:00
|
|
|
|
2011-07-18 12:54:35 +08:00
|
|
|
bool ParseValue(Type *Ty, Value *&V, LocTy &Loc,
|
2009-01-02 15:01:27 +08:00
|
|
|
PerFunctionState &PFS) {
|
|
|
|
Loc = Lex.getLoc();
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
return ParseValue(Ty, V, &PFS);
|
2009-01-02 15:01:27 +08:00
|
|
|
}
|
2009-01-03 06:46:48 +08:00
|
|
|
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
bool ParseTypeAndValue(Value *&V, PerFunctionState *PFS);
|
|
|
|
bool ParseTypeAndValue(Value *&V, PerFunctionState &PFS) {
|
|
|
|
return ParseTypeAndValue(V, &PFS);
|
|
|
|
}
|
2009-01-02 15:01:27 +08:00
|
|
|
bool ParseTypeAndValue(Value *&V, LocTy &Loc, PerFunctionState &PFS) {
|
|
|
|
Loc = Lex.getLoc();
|
|
|
|
return ParseTypeAndValue(V, PFS);
|
|
|
|
}
|
2009-10-28 03:13:16 +08:00
|
|
|
bool ParseTypeAndBasicBlock(BasicBlock *&BB, LocTy &Loc,
|
|
|
|
PerFunctionState &PFS);
|
|
|
|
bool ParseTypeAndBasicBlock(BasicBlock *&BB, PerFunctionState &PFS) {
|
|
|
|
LocTy Loc;
|
|
|
|
return ParseTypeAndBasicBlock(BB, Loc, PFS);
|
|
|
|
}
|
2009-12-04 07:40:58 +08:00
|
|
|
|
2010-02-13 04:49:41 +08:00
|
|
|
|
2009-01-02 15:01:27 +08:00
|
|
|
struct ParamInfo {
|
|
|
|
LocTy Loc;
|
|
|
|
Value *V;
|
2013-01-31 08:29:54 +08:00
|
|
|
AttributeSet Attrs;
|
|
|
|
ParamInfo(LocTy loc, Value *v, AttributeSet attrs)
|
2009-01-02 15:01:27 +08:00
|
|
|
: Loc(loc), V(v), Attrs(attrs) {}
|
|
|
|
};
|
|
|
|
bool ParseParameterList(SmallVectorImpl<ParamInfo> &ArgList,
|
2014-08-26 08:33:28 +08:00
|
|
|
PerFunctionState &PFS,
|
|
|
|
bool IsMustTailCall = false,
|
|
|
|
bool InVarArgsFunc = false);
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2015-09-25 07:34:52 +08:00
|
|
|
bool
|
|
|
|
ParseOptionalOperandBundles(SmallVectorImpl<OperandBundleDef> &BundleList,
|
|
|
|
PerFunctionState &PFS);
|
|
|
|
|
2015-08-01 01:58:14 +08:00
|
|
|
bool ParseExceptionArgs(SmallVectorImpl<Value *> &Args,
|
|
|
|
PerFunctionState &PFS);
|
|
|
|
|
2010-01-06 06:22:14 +08:00
|
|
|
// Constant Parsing.
|
2014-04-16 12:21:27 +08:00
|
|
|
bool ParseValID(ValID &ID, PerFunctionState *PFS = nullptr);
|
2011-07-18 12:54:35 +08:00
|
|
|
bool ParseGlobalValue(Type *Ty, Constant *&V);
|
2010-01-06 06:22:14 +08:00
|
|
|
bool ParseGlobalTypeAndValue(Constant *&V);
|
LLParser: Handle BlockAddresses on-the-fly
Previously all `blockaddress()` constants were treated as forward
references. They were resolved twice: once at the end of the function
in question, and again at the end of the module. Furthermore, if the
same blockaddress was referenced N times, the parser created N distinct
`GlobalVariable`s (one for each reference).
Instead, resolve all block addresses at the beginning of the function,
creating the standard `BasicBlock` forward references used for all other
basic block references. After the function, all references can be
resolved immediately. To check for the condition of parsing block
addresses from within the same function, I created a reference to the
current per-function-state in `BlockAddressPFS`.
Also, create only one forward-reference per basic block. Because
forward references to block addresses are rare, the data structure here
shouldn't matter. If somehow it does someday, this can be pretty easily
changed to a `DenseMap<std::pair<ValID, ValID>, GV>`.
This is part of PR20515.
llvm-svn: 215952
2014-08-19 08:13:19 +08:00
|
|
|
bool ParseGlobalValueVector(SmallVectorImpl<Constant *> &Elts);
|
2015-01-07 06:55:16 +08:00
|
|
|
bool parseOptionalComdat(StringRef GlobalName, Comdat *&C);
|
IR: Make metadata typeless in assembly
Now that `Metadata` is typeless, reflect that in the assembly. These
are the matching assembly changes for the metadata/value split in
r223802.
- Only use the `metadata` type when referencing metadata from a call
intrinsic -- i.e., only when it's used as a `Value`.
- Stop pretending that `ValueAsMetadata` is wrapped in an `MDNode`
when referencing it from call intrinsics.
So, assembly like this:
define @foo(i32 %v) {
call void @llvm.foo(metadata !{i32 %v}, metadata !0)
call void @llvm.foo(metadata !{i32 7}, metadata !0)
call void @llvm.foo(metadata !1, metadata !0)
call void @llvm.foo(metadata !3, metadata !0)
call void @llvm.foo(metadata !{metadata !3}, metadata !0)
ret void, !bar !2
}
!0 = metadata !{metadata !2}
!1 = metadata !{i32* @global}
!2 = metadata !{metadata !3}
!3 = metadata !{}
turns into this:
define @foo(i32 %v) {
call void @llvm.foo(metadata i32 %v, metadata !0)
call void @llvm.foo(metadata i32 7, metadata !0)
call void @llvm.foo(metadata i32* @global, metadata !0)
call void @llvm.foo(metadata !3, metadata !0)
call void @llvm.foo(metadata !{!3}, metadata !0)
ret void, !bar !2
}
!0 = !{!2}
!1 = !{i32* @global}
!2 = !{!3}
!3 = !{}
I wrote an upgrade script that handled almost all of the tests in llvm
and many of the tests in cfe (even handling many `CHECK` lines). I've
attached it (or will attach it in a moment if you're speedy) to PR21532
to help everyone update their out-of-tree testcases.
This is part of PR21532.
llvm-svn: 224257
2014-12-16 03:07:53 +08:00
|
|
|
bool ParseMetadataAsValue(Value *&V, PerFunctionState &PFS);
|
2015-02-13 09:26:47 +08:00
|
|
|
bool ParseValueAsMetadata(Metadata *&MD, const Twine &TypeMsg,
|
|
|
|
PerFunctionState *PFS);
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
bool ParseMetadata(Metadata *&MD, PerFunctionState *PFS);
|
2015-01-13 05:23:11 +08:00
|
|
|
bool ParseMDTuple(MDNode *&MD, bool IsDistinct = false);
|
2015-01-13 06:26:48 +08:00
|
|
|
bool ParseMDNode(MDNode *&MD);
|
|
|
|
bool ParseMDNodeTail(MDNode *&MD);
|
IR: Make metadata typeless in assembly
Now that `Metadata` is typeless, reflect that in the assembly. These
are the matching assembly changes for the metadata/value split in
r223802.
- Only use the `metadata` type when referencing metadata from a call
intrinsic -- i.e., only when it's used as a `Value`.
- Stop pretending that `ValueAsMetadata` is wrapped in an `MDNode`
when referencing it from call intrinsics.
So, assembly like this:
define @foo(i32 %v) {
call void @llvm.foo(metadata !{i32 %v}, metadata !0)
call void @llvm.foo(metadata !{i32 7}, metadata !0)
call void @llvm.foo(metadata !1, metadata !0)
call void @llvm.foo(metadata !3, metadata !0)
call void @llvm.foo(metadata !{metadata !3}, metadata !0)
ret void, !bar !2
}
!0 = metadata !{metadata !2}
!1 = metadata !{i32* @global}
!2 = metadata !{metadata !3}
!3 = metadata !{}
turns into this:
define @foo(i32 %v) {
call void @llvm.foo(metadata i32 %v, metadata !0)
call void @llvm.foo(metadata i32 7, metadata !0)
call void @llvm.foo(metadata i32* @global, metadata !0)
call void @llvm.foo(metadata !3, metadata !0)
call void @llvm.foo(metadata !{!3}, metadata !0)
ret void, !bar !2
}
!0 = !{!2}
!1 = !{i32* @global}
!2 = !{!3}
!3 = !{}
I wrote an upgrade script that handled almost all of the tests in llvm
and many of the tests in cfe (even handling many `CHECK` lines). I've
attached it (or will attach it in a moment if you're speedy) to PR21532
to help everyone update their out-of-tree testcases.
This is part of PR21532.
llvm-svn: 224257
2014-12-16 03:07:53 +08:00
|
|
|
bool ParseMDNodeVector(SmallVectorImpl<Metadata *> &MDs);
|
2015-04-25 05:21:57 +08:00
|
|
|
bool ParseMetadataAttachment(unsigned &Kind, MDNode *&MD);
|
2015-04-25 05:29:36 +08:00
|
|
|
bool ParseInstructionMetadata(Instruction &Inst);
|
2015-04-25 06:04:41 +08:00
|
|
|
bool ParseOptionalFunctionMetadata(Function &F);
|
2010-01-06 06:22:14 +08:00
|
|
|
|
2015-02-05 06:05:21 +08:00
|
|
|
template <class FieldTy>
|
|
|
|
bool ParseMDField(LocTy Loc, StringRef Name, FieldTy &Result);
|
2015-01-20 10:42:29 +08:00
|
|
|
template <class FieldTy> bool ParseMDField(StringRef Name, FieldTy &Result);
|
2015-01-20 07:32:36 +08:00
|
|
|
template <class ParserTy>
|
2015-01-20 07:39:32 +08:00
|
|
|
bool ParseMDFieldsImplBody(ParserTy parseField);
|
|
|
|
template <class ParserTy>
|
2015-01-20 07:32:36 +08:00
|
|
|
bool ParseMDFieldsImpl(ParserTy parseField, LocTy &ClosingLoc);
|
2015-01-14 05:10:44 +08:00
|
|
|
bool ParseSpecializedMDNode(MDNode *&N, bool IsDistinct = false);
|
2015-02-10 09:08:16 +08:00
|
|
|
|
|
|
|
#define HANDLE_SPECIALIZED_MDNODE_LEAF(CLASS) \
|
|
|
|
bool Parse##CLASS(MDNode *&Result, bool IsDistinct);
|
|
|
|
#include "llvm/IR/Metadata.def"
|
2015-01-14 05:10:44 +08:00
|
|
|
|
2009-01-02 15:01:27 +08:00
|
|
|
// Function Parsing.
|
|
|
|
struct ArgInfo {
|
|
|
|
LocTy Loc;
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
Type *Ty;
|
2013-01-31 08:29:54 +08:00
|
|
|
AttributeSet Attrs;
|
2009-01-02 15:01:27 +08:00
|
|
|
std::string Name;
|
2013-01-31 08:29:54 +08:00
|
|
|
ArgInfo(LocTy L, Type *ty, AttributeSet Attr, const std::string &N)
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
: Loc(L), Ty(ty), Attrs(Attr), Name(N) {}
|
2009-01-02 15:01:27 +08:00
|
|
|
};
|
Land the long talked about "type system rewrite" patch. This
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
llvm-svn: 134829
2011-07-10 01:41:24 +08:00
|
|
|
bool ParseArgumentList(SmallVectorImpl<ArgInfo> &ArgList, bool &isVarArg);
|
2009-01-02 15:01:27 +08:00
|
|
|
bool ParseFunctionHeader(Function *&Fn, bool isDefine);
|
|
|
|
bool ParseFunctionBody(Function &Fn);
|
|
|
|
bool ParseBasicBlock(PerFunctionState &PFS);
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2014-04-25 04:14:34 +08:00
|
|
|
enum TailCallType { TCT_None, TCT_Tail, TCT_MustTail };
|
|
|
|
|
2009-12-30 13:23:43 +08:00
|
|
|
// Instruction Parsing. Each instruction parsing routine can return with a
|
|
|
|
// normal result, an error result, or return having eaten an extra comma.
|
|
|
|
enum InstResult { InstNormal = 0, InstError = 1, InstExtraComma = 2 };
|
|
|
|
int ParseInstruction(Instruction *&Inst, BasicBlock *BB,
|
|
|
|
PerFunctionState &PFS);
|
2009-01-02 15:01:27 +08:00
|
|
|
bool ParseCmpPredicate(unsigned &Pred, unsigned Opc);
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2011-06-17 14:49:41 +08:00
|
|
|
bool ParseRet(Instruction *&Inst, BasicBlock *BB, PerFunctionState &PFS);
|
2009-01-02 15:01:27 +08:00
|
|
|
bool ParseBr(Instruction *&Inst, PerFunctionState &PFS);
|
|
|
|
bool ParseSwitch(Instruction *&Inst, PerFunctionState &PFS);
|
2009-10-28 08:19:10 +08:00
|
|
|
bool ParseIndirectBr(Instruction *&Inst, PerFunctionState &PFS);
|
2009-01-02 15:01:27 +08:00
|
|
|
bool ParseInvoke(Instruction *&Inst, PerFunctionState &PFS);
|
2011-07-31 14:30:59 +08:00
|
|
|
bool ParseResume(Instruction *&Inst, PerFunctionState &PFS);
|
2015-08-01 01:58:14 +08:00
|
|
|
bool ParseCleanupRet(Instruction *&Inst, PerFunctionState &PFS);
|
|
|
|
bool ParseCatchRet(Instruction *&Inst, PerFunctionState &PFS);
|
[IR] Reformulate LLVM's EH funclet IR
While we have successfully implemented a funclet-oriented EH scheme on
top of LLVM IR, our scheme has some notable deficiencies:
- catchendpad and cleanupendpad are necessary in the current design
but they are difficult to explain to others, even to seasoned LLVM
experts.
- catchendpad and cleanupendpad are optimization barriers. They cannot
be split and force all potentially throwing call-sites to be invokes.
This has a noticable effect on the quality of our code generation.
- catchpad, while similar in some aspects to invoke, is fairly awkward.
It is unsplittable, starts a funclet, and has control flow to other
funclets.
- The nesting relationship between funclets is currently a property of
control flow edges. Because of this, we are forced to carefully
analyze the flow graph to see if there might potentially exist illegal
nesting among funclets. While we have logic to clone funclets when
they are illegally nested, it would be nicer if we had a
representation which forbade them upfront.
Let's clean this up a bit by doing the following:
- Instead, make catchpad more like cleanuppad and landingpad: no control
flow, just a bunch of simple operands; catchpad would be splittable.
- Introduce catchswitch, a control flow instruction designed to model
the constraints of funclet oriented EH.
- Make funclet scoping explicit by having funclet instructions consume
the token produced by the funclet which contains them.
- Remove catchendpad and cleanupendpad. Their presence can be inferred
implicitly using coloring information.
N.B. The state numbering code for the CLR has been updated but the
veracity of it's output cannot be spoken for. An expert should take a
look to make sure the results are reasonable.
Reviewers: rnk, JosephTremoulet, andrew.w.kaylor
Differential Revision: http://reviews.llvm.org/D15139
llvm-svn: 255422
2015-12-12 13:38:55 +08:00
|
|
|
bool ParseCatchSwitch(Instruction *&Inst, PerFunctionState &PFS);
|
2015-08-01 01:58:14 +08:00
|
|
|
bool ParseCatchPad(Instruction *&Inst, PerFunctionState &PFS);
|
|
|
|
bool ParseCleanupPad(Instruction *&Inst, PerFunctionState &PFS);
|
2009-01-03 06:46:48 +08:00
|
|
|
|
2009-01-05 16:24:46 +08:00
|
|
|
bool ParseArithmetic(Instruction *&I, PerFunctionState &PFS, unsigned Opc,
|
|
|
|
unsigned OperandType);
|
2009-01-02 15:01:27 +08:00
|
|
|
bool ParseLogical(Instruction *&I, PerFunctionState &PFS, unsigned Opc);
|
|
|
|
bool ParseCompare(Instruction *&I, PerFunctionState &PFS, unsigned Opc);
|
|
|
|
bool ParseCast(Instruction *&I, PerFunctionState &PFS, unsigned Opc);
|
|
|
|
bool ParseSelect(Instruction *&I, PerFunctionState &PFS);
|
2009-01-05 16:18:44 +08:00
|
|
|
bool ParseVA_Arg(Instruction *&I, PerFunctionState &PFS);
|
2009-01-02 15:01:27 +08:00
|
|
|
bool ParseExtractElement(Instruction *&I, PerFunctionState &PFS);
|
|
|
|
bool ParseInsertElement(Instruction *&I, PerFunctionState &PFS);
|
|
|
|
bool ParseShuffleVector(Instruction *&I, PerFunctionState &PFS);
|
2009-12-30 13:27:33 +08:00
|
|
|
int ParsePHI(Instruction *&I, PerFunctionState &PFS);
|
2011-08-13 04:24:12 +08:00
|
|
|
bool ParseLandingPad(Instruction *&I, PerFunctionState &PFS);
|
2014-04-25 04:14:34 +08:00
|
|
|
bool ParseCall(Instruction *&I, PerFunctionState &PFS,
|
|
|
|
CallInst::TailCallKind IsTail);
|
2011-06-17 11:16:47 +08:00
|
|
|
int ParseAlloc(Instruction *&I, PerFunctionState &PFS);
|
2011-11-27 14:56:53 +08:00
|
|
|
int ParseLoad(Instruction *&I, PerFunctionState &PFS);
|
|
|
|
int ParseStore(Instruction *&I, PerFunctionState &PFS);
|
2011-08-13 06:50:01 +08:00
|
|
|
int ParseCmpXchg(Instruction *&I, PerFunctionState &PFS);
|
|
|
|
int ParseAtomicRMW(Instruction *&I, PerFunctionState &PFS);
|
2011-07-26 07:16:38 +08:00
|
|
|
int ParseFence(Instruction *&I, PerFunctionState &PFS);
|
2009-12-30 13:27:33 +08:00
|
|
|
int ParseGetElementPtr(Instruction *&I, PerFunctionState &PFS);
|
|
|
|
int ParseExtractValue(Instruction *&I, PerFunctionState &PFS);
|
|
|
|
int ParseInsertValue(Instruction *&I, PerFunctionState &PFS);
|
2014-08-20 05:30:15 +08:00
|
|
|
|
|
|
|
// Use-list order directives.
|
|
|
|
bool ParseUseListOrder(PerFunctionState *PFS = nullptr);
|
|
|
|
bool ParseUseListOrderBB();
|
|
|
|
bool ParseUseListOrderIndexes(SmallVectorImpl<unsigned> &Indexes);
|
|
|
|
bool sortUseListOrder(Value *V, ArrayRef<unsigned> Indexes, SMLoc Loc);
|
2009-01-02 15:01:27 +08:00
|
|
|
};
|
2015-06-23 17:49:53 +08:00
|
|
|
} // End llvm namespace
|
2009-01-02 15:01:27 +08:00
|
|
|
|
|
|
|
#endif
|