LLVM程序员手册——LLVM4.0文档-可译网_llvm编译器实战教程pdf

LLVM

需积分: 45 23 浏览量更新于2023-05-21 评论 1 收藏 1.09MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源评论

资源推荐

2017/5/17 Ӥ܌9)50LLVM ᑕଧާಋٙ —— LLVM 4.0 ෈໩ - ݢᦲᗑ
ᒫ 1 ᶭҁو 41 ᶭ҂https://coyee.com/article/compare/10594-llvm-programmer-s-manual-llvm-4-0-documentation
Ḓᶭ ଠ࣋ ஙᦲ ޑ~ ӝۜ
൤ᔱ෈ᒍ
"
+
ጭ୯ጭ୯ ےفݢᦲᗑےفݢᦲᗑ
 LLVM ᑕଧާಋٙᑕଧާಋٙ —— LLVM 4.0 ෈໩෈໩ [૪ᘉᦲ૪ᘉᦲ]
LLVM Programmer’s Manual — LLVM 4.0 documentation
ܻ෈ ᦲ෈ ඙֢
Introduction
This document is meant to highlight some of the important classes
and interfaces available in the LLVM source-base. This manual is not
intended to explain what LLVM is, how it works, and what LLVM code
looks like. It assumes that you know the basics of LLVM and are
interested in writing transformations or otherwise analyzing or
manipulating the code.
This document should get you oriented so that you can find your way
in the continuously growing source code that makes up the LLVM
infrastructure. Note that this manual is not intended to serve as a
replacement for reading the source code, so if you think there should
be a method in one of these classes to do something, but it’s not
listed, check the source. Links to the doxygensources are provided to
make this as easy as possible.
ڹ᥺ڹ᥺
๜෈໩෰ࣁՕᕨLLVMӾӞԶ᯿ᥝጱᔄ޾ളݗ๜෈໩ӧ಑ᓒՕᕨՋԍฎ
LLVM҅LLVMฎই֜ૡ֢ጱ҅ᬮํLLVMጱդᎱړຉ๜෈؃ᦡ֦૪ᕪ
LLVMํ๜ጱԧᥴ҅ଚ󰪉ഘ҅౲ᘏړຉ޾ᖌಷٌӾጱդᎱఽي᪁
๜෈໩տᕳ֦೰ොݻ҅ᦏ֦ݢզࣁӧෙᳩጱLLVMຝ຅ӾጱդᎱӾ҅
ತک֦ጱොݻ᧗ဳ఺҅ᴅ᧛๜෈໩ଚӧᚆ๊դLLVMრդᎱጱᴅ᧛҅ಅ
զইຎ֦మັತ຤Զᔄᚆ؉ԶՋԍ҅๜෈໩ଚӧᚆࢧᒼ֦ᬯӻᳯ󰵭҅ಅ
զ֦ᬮฎ஑ັತრᎱզӥᬯӻ᱾ളฎLLVMጱdoxygen෈໩҅ݢզො׎
ጱᦏ֦ັತమᥝጱӳᥜ
ᔿྋᘉᦲᔿྋᘉᦲ
The first section of this document describes general information that
is useful to know when working in the LLVM infrastructure, and the
second describes the Core LLVM classes. In the future this manual
will be extended with information describing how to use extension
libraries, such as dominator information, CFG traversal routines, and
useful utilities like the InstVisitor(doxygen) template.
General Information
This section contains general information that is useful if you are
working in the LLVM source-base, but that isn’t specific to any
particular API.
๜෈ᒫӞ᮱ړՕᕨֵአLLVMᬦᑕӾ҅ӞԶଉአጱᎣᦩᅩ҅ᒫԫ᮱ړտ
Օᕨ҅LLVMጱ໐ஞᔄࣁ෭ݸጱ෈໩ಋٙӾ҅տᖀᖅ୊֐ᦖᥴইֵ֜
አಘ઀ପֺ҅ইdominator҅CFG ഴګၞ҅ᬮํӞԶํአጱૡֺٍ҅
ই InstVisitor(doxygen)ཛྷᇇ
 
๜מ௳๜מ௳
๜ᒍᜓ۱ތֵአLLVMᬦᑕӾ҅ଉአጱמ௳҅֕ฎଚ๚ࣁAPI෈໩Ӿڜ
ڊ
ᔿྋᘉᦲᔿྋᘉᦲ
The C++ Standard Template Library
LLVM makes heavy use of the C++ Standard Template Library (STL),
perhaps much more than you are used to, or have seen before.
Because of this, you might want to do a little background reading in
the techniques used and capabilities of the library. There are many
good pages that discuss the STL, and several books on the subject
that you can get, so it will not be discussed in this document.
Here are some useful links:
1.  cppreference.com - an excellent reference for the STL and
other parts of the standard C++ library.
2.  C++ In a Nutshell - This is an O’Reilly book in the making. It
has a decent Standard Library Reference that rivals
Dinkumware’s, and is unfortunately no longer free since the
book has been published.
3.  C++ Frequently Asked Questions.
4.  SGI’s STL Programmer’s Guide - Contains a useful Introduction
to the STL.
5.  Bjarne Stroustrup’s C++ Page.
6.  Bruce Eckel’s Thinking in C++, 2nd ed. Volume 2 Revision 4.0
(even better, get the book).
C++ ຽٵཛྷᇇପຽٵཛྷᇇପ
LLVMጱդᎱӾᶋଉׁᩢC++ጱຽٵཛྷᇇପ(STL), ֵአጱහᰁݢᚆྲ֦አ
ጱᬮಅզ֦҅ᴅ᧛๜෈ڹ֦҅ᵱᥝSTLํ๜ጱԧᥴ҅ᬯ໏಍ᚆԧ
ᥴ๜෈൉کጱದૣ޾ପጱۑᚆᗑӤ૪ᕪํᶋଉӿጱᩒාᬮํԡᔁ๶
ᦖᥴSTL֦҅ݢզ݇ᘍইӥጱᩒා҅๜෈ӧٚᩣᬿ
1.  cppreference.com - ᶋଉ༉ጱSTLಋٙ҅ᬮํӞԶٌ՜C++ጱପ
ጱಋٙ
2.  C++ In a Nutshell - ᬯฎӞ๜O’ReillyڊᇇጱԡᔁԡӾၿ݊ጱฎ
๋ෛጱପ֕ฎᬯ๜ԡ૪ᕪݎᤈ҅ಅզӧٚعᩇӥ󰪚
3.  C++ Frequently Asked Questions.
4.  SGI’s STL Programmer’s Guide -  STLํᧇᕡጱՕᕨ.
5.  Bjarne Stroustrup’s C++ Page.
6.  Bruce Eckel’s Thinking in C++, 2nd ed. Volume 2 Revision 4.0
(even better, get the book).
ᔿྋᘉᦲᔿྋᘉᦲ
You are also encouraged to take a look at the LLVM Coding
Standards guide which focuses on how to write maintainable code
more than where to put your curly braces.
Other useful references
1.  Using static and shared libraries across platforms
Important and useful LLVM APIs
ᬮἩۜ఍ັ󰌂LLVMᖫᎱຽٵ೰ܖ҅ᧆ೰ܖጱ᯿ᅩฎই֜ᖫٟݢᖌಷጱդ
Ꮁ҅ᘒӧฎ఍ጱೡݩනࣁߺ᯾
ٌ՜ํአጱ݇ᘍٌ՜ํአጱ݇ᘍ
1.  ᪜ଘݣֵአᶉா޾وՁପ
᯿ᥝ޾ํአጱ᯿ᥝ޾ํአጱLLVM API
ᔿྋᘉᦲᔿྋᘉᦲ
!

2017/5/17 Ӥ܌9)50LLVM ᑕଧާಋٙ —— LLVM 4.0 ෈໩ - ݢᦲᗑ

ᒫ 2 ᶭҁو 41 ᶭ҂https://coyee.com/article/compare/10594-llvm-programmer-s-manual-llvm-4-0-documentation

Here we highlight some LLVM APIs that are generally useful and

good to know about when writing transformations.

The isa<>, cast<> and dyn_cast<> templates

The LLVM source-base makes extensive use of a custom form of

RTTI. These templates have many similarities to the

C++ dynamic_cast<> operator, but they don’t have some

drawbacks (primarily stemming from the fact

that dynamic_cast<> only works on classes that have a v-table).

Because they are used so often, you must know what they do and

how they work. All of these templates are defined in

the llvm/Support/Casting.h (doxygen) file (note that you very

rarely have to include this file directly).

ࣁᬯ᯾҅౯ժ୩᧣ӞԶLLVM API҅ժ᭗ଉฎํአጱ҅ଚӬ୮֦ᖫٟ󰪉

ഘ෸๋অԧᥴӞӥ

The isa<>, cast<> and dyn_cast<> templates

LLVMრդᎱପଠာֵአԧӞᐿᛔԎ୵ୗጱRTTI ᬯԶཛྷ຃ӨC ++

dynamic_cast <>඙֢ᒧํᦜፘ֒ԏ҅֕ժဌํӞԶᗌᅩҁԆᥝრ

ᛔdynamic_cast <>Րᭇአԭٍํv-tableጱᔄ҂ ࢩԅժᕪଉᤩֵ

አ֦҅஠ᶳᎣ᭲՜ժ؉Ջԍզ݊ժই֜ૡ֢ ಅํᬯԶཛྷ຃᮷

ࣁllvm/Support/Casting.h (doxygen)෈կӾԎҁ᧗ဳ఺҅఍உ

ᵱᥝፗള۱ތྌ෈կ҂

isa<>:

The isa<> operator works exactly like the Java “instanceof”

operator. It returns true or false depending on whether a reference or

pointer points to an instance of the specified class. This can be very

useful for constraint checking of various sorts (example below).

cast<>:

The cast<> operator is a “checked cast” operation. It converts a

pointer or reference from a base class to a derived class, causing an

assertion failure if it is not really an instance of the right type. This

should be used in cases where you have some information that

makes you believe that something is of the right type. An example of

the isa<> and cast<> template is:

isa<>:

isa<> ඙֢ᒧ؟Javaጱ"instanceof"඙֢ᒧ.ೲᆙӞӻ୚አ౲೰ᰒฎވ

೰ݻӞӻᇙᔄጱֺ๶ᬬࢧฎވ.ᬯӻ඙֢ᒧࣁݱᐿᕅ๳༄ັӾஉํአ

(ӥᶎํֺৼ).

cast<>:

cast<> ඙֢ᒧฎӞӻ"༄ັᬦጱ󰪉ഘ"඙֢.Ӟӻ೰ᰒ౲୚አ՗ᔄ󰪉

ഘکၝኞᔄ, ইຎᔄࣳᲙ᧏୚ݎෙ᥺Კ᧏.ᬯଫᧆࣁ୮֦ፘמֺጱᔄࣳ

෸ֵአ. Ӟӻisa<> ޾ cast<> ཛྷ຃ጱֺৼฎ:

ᔿྋᘉᦲᔿྋᘉᦲ

Note that you should not use an isa<> test followed by a cast<>,

for that use the dyn_cast<> operator.

dyn_cast<>:

The dyn_cast<> operator is a “checking cast” operation. It checks

to see if the operand is of the specified type, and if so, returns a

pointer to it (this operator does not work with references). If the

operand is not of the correct type, a null pointer is returned. Thus,

this works very much like the dynamic_cast<> operator in C++, and

should be used in the same circumstances. Typically,

the dyn_cast<> operator is used in an if statement or some other

flow control statement like this:

᧗ဳ఺҅఍ӧଫᧆࣁݸᶎ᪙፳Ӟӻcast <>෸ֵአisa <>ၥᦶ҅ԭᮎᐿ

ఘ٭ֵአdyn_cast <>ᬩᓒᒧ

dyn_cast<>:

dyn_cast <>඙֢ᒧฎӞӻ“༄ັ󰪉ഘҁchecking cast҂”඙֢ ༄ັ

඙֢හฎވฎ೰ጱᔄࣳ҅ইຎฎᬯ໏҅ᬬࢧӞӻ೰ݻጱ೰ᰒҁᧆ඙

֢ᒧӧᭇአԭ୚አ҂ ইຎ඙֢හӧฎྋᏟጱᔄࣳ҅ڞᬬࢧᑮ೰ᰒ ࢩ

ྌ҅ᬯ໏؉ᶋଉ؟C++Ӿጱdynamic_cast <>ᬩᓒᒧ҅ଚӬଫᧆࣁፘݶጱ

ఘ٭ӥֵአ ᭗ଉ҅dyn_cast <>ᬩᓒᒧአԭif᧍ݙ౲ٌ՜ӞԶၞᑕഴګ

᧍ݙ҅ইӥಅᐏғ

ᔿྋᘉᦲᔿྋᘉᦲ

This form of the if statement effectively combines together a call

to isa<> and a call to cast<> into one statement, which is very

convenient.

Note that the dyn_cast<> operator, like C++’s dynamic_cast<> or

Java’s instanceof operator, can be abused. In particular, you

should not use big chained if/then/else blocks to check for lots

of different variants of classes. If you find yourself wanting to do this,

it is much cleaner and more efficient to use the InstVisitor class

to dispatch over the instruction type directly.

ᬯᐿ୵ୗጱif᧍ݙํපࣈᕟݳԧ᧣አisa <>޾᧣አcast <>کӞӻ᧍ݙӾ҅

ᬯฎᶋଉො׎ጱ

᧗ဳ఺҅dyn_cast <>ᬩᓒᒧ҅ইC++ጱdynamic_cast <>౲Javaጱ

instanceofᬩᓒᒧ҅ݢᚆտᤩᄂአ ᇙڦฎ҅఍ӧଫᧆֵአӞᔮ

ڜif/then/else ࣘ๶༄ັᦜӧݶᔄጱݒ֛ ইຎ఍ݎሿᛔ૩మᥝᬯ

໏؉ֵ҅አInstVisitorᔄፗളݎڊ೰եᔄࣳๅԅႴ၄Ԟๅํප

ᔿྋᘉᦲᔿྋᘉᦲ

cast_or_null<>:

The cast_or_null<> operator works just like the cast<> operator,

except that it allows for a null pointer as an argument (which it then

propagates). This can sometimes be useful, allowing you to combine

several null checks into one.

dyn_cast_or_null<>:

cast_or_null<>:

cast_or_null <>඙֢ᒧӨcast <>඙֢ᒧᔄ֒҅ݝฎ꧋ᦜӞӻᑮ೰ᰒ֢

ԅ݇හҁᆐݸփඎ҂ ᬯํ෸ݢᚆฎํአጱ҅꧋ᦜ఍پӻᑮ༄ັݳଚ

ԅӞӻ

dyn_cast_or_null<>:

ᔿྋᘉᦲᔿྋᘉᦲ

static bool isLoopInvariant(const Value *V, const Loop *L) {

if (isa<Constant>(V) || isa<Argument>(V) || isa<GlobalValue>(V))

return true;

// Otherwise, it must be an instruction...

return !L->contains(cast<Instruction>(V)->getParent());

}

static bool isLoopInvariant(const Value *V, const Loop *L) {

if (isa<Constant>(V) || isa<Argument>(V) || isa<GlobalValue>(V))

return true;

// Otherwise, it must be an instruction...

return !L->contains(cast<Instruction>(V)->getParent());

}

if (AllocationInst *AI = dyn_cast<AllocationInst>(Val)) {

// ...

}

if (AllocationInst *AI = dyn_cast<AllocationInst>(Val)) {

// ...

}

2017/5/17 Ӥ܌9)50LLVM ᑕଧާಋٙ —— LLVM 4.0 ෈໩ - ݢᦲᗑ

ᒫ 3 ᶭҁو 41 ᶭ҂https://coyee.com/article/compare/10594-llvm-programmer-s-manual-llvm-4-0-documentation

The dyn_cast_or_null<> operator works just like

the dyn_cast<> operator, except that it allows for a null pointer as

an argument (which it then propagates). This can sometimes be

useful, allowing you to combine several null checks into one.

These five templates can be used with any classes, whether they

have a v-table or not. If you want to add support for these templates,

see the document How to set up LLVM-style RTTI for your class

hierarchy

dyn_cast_or_null <>඙֢ᒧӨdyn_cast <>ᬩᓒᒧᔄ֒҅ݝӧᬦ꧋ᦜӞ

ӻᑮ೰ᰒ֢ԅ݇හҁᆐݸփඎ҂ ᬯํ෸ݢᚆฎํአጱ҅꧋ᦜ఍پӻ

ᑮ༄ັݳଚԅӞӻ

ᬯԲӻཛྷ຃ݢզӨձ֜ᔄӞֵ᩸አ҅෫ᦞժฎވٍํᡦᤒҁv-

table҂ ইຎᥝႲےᬯԶཛྷ຃ጱඪ೮҅᧗݇ᴅ෈໩ই֜ԅᔄེᕮ຅

ᦡᗝLLVM󰵻໒ጱRTTI

Passing strings (the StringRef and Twine classes)

Although LLVM generally does not do much string manipulation, we

do have several important APIs which take strings. Two important

examples are the Value class – which has names for instructions,

functions, etc. – and the StringMap class which is used extensively

in LLVM and Clang.

These are generic classes, and they need to be able to accept

strings which may have embedded null characters. Therefore, they

cannot simply take a const char *, and taking

a conststd::string& requires clients to perform a heap allocation

which is usually unnecessary. Instead, many LLVM APIs use

a StringRef or a const Twine& for passing strings efficiently.

փ᭓ᒧԀҁփ᭓ᒧԀҁStringRef޾޾Twineᔄ҂ᔄ҂

ᡱᆐLLVM᭗ଉဌํ؉ጱᒧԀ඙֢҅֕౯ժᏟํپӻቘᒧԀ

ጱ᯿ᥝAPI ӷӻ᯿ᥝጱֺৼฎValueᔄ - ํ೰ե҅ڍහᒵጱݷᑍզ݊

ࣁLLVM޾ClangӾଠာֵአጱStringMapᔄ

ᬯԶฎ᭗አᔄ҅ժᵱᥝᚆളݑݢᚆ۱ތᑮᒧጱᒧԀ ࢩྌ҅

ժӧᚆᓌܔࣈֵአconst char *҅ଚӬֵአconststd :: stringѿᥝ࿢ಁ

ᒒಗᤈ᭗ଉӧ஠ᥝጱړᯈ ፘݍ҅ᦜLLVM APIֵአStringRef౲

const Twineѿ๶ํපࣈփ᭓ᒧԀ

ᔿྋᘉᦲᔿྋᘉᦲ

The StringRef class

The StringRef data type represents a reference to a constant string

(a character array and a length) and supports the common operations

available on std::string, but does not require heap allocation.

It can be implicitly constructed using a C style null-terminated string,

an std::string, or explicitly with a character pointer and length.

For example, the StringRef find function is declared as:

iterator find(StringRef Key);

and clients can call it using any one of:

Map.find("foo"); // Lookup "foo"

Map.find(std::string("bar")); // Lookup "bar"

Map.find(StringRef("\0baz", 4)); // Lookup "\0baz"

StringRefᔄᔄ

StringRefහഝᔄࣳᤒᐏଉᰁᒧԀҁᒧහᕟ޾ᳩଶ҂ጱ୚አ҅ଚඪ

೮std :: stringӤݢአጱଉአ඙֢҅֕ӧᵱᥝړᯈ

ݢզᵌୗࣈֵአC󰵻໒ጱզnullᕮጱᒧԀ҅std :: string҅౲ดୗࣈ

ֵአᒧ೰ᰒ޾ᳩଶ๶຅᭜ ֺই҅StringRef findڍහกԅғ

iterator find(StringRef Key);

ಁᒒݢզֵአզӥձ֜Ӟᐿ๶᧣አғ

Map.find("foo"); // Lookup "foo"

Map.find(std::string("bar")); // Lookup "bar"

Map.find(StringRef("\0baz", 4)); // Lookup "\0baz"

ᔿྋᘉᦲᔿྋᘉᦲ

Similarly, APIs which need to return a string may return

a StringRef instance, which can be used directly or converted to

an std::string using the str member function.

Seellvm/ADT/StringRef.h (doxygen) for more information.

You should rarely use the StringRef class directly, because it

contains pointers to external memory it is not generally safe to store

an instance of the class (unless you know that the external storage

will not be freed). StringRef is small and pervasive enough in LLVM

that it should always be passed by value.

The Twine class

The Twine (doxygen) class is an efficient way for APIs to accept

concatenated strings. For example, a common LLVM paradigm is to

name one instruction based on the name of another instruction with

a suffix, for example:

ᔄ֒ࣈ҅ᵱᥝᬬࢧᒧԀጱAPIݢᚆտᬬࢧӞӻStringRefֺ҅ݢզፗ

ളֵአ౲ᘏֵአstr౮ާڍහ󰪉ഘԅstd :: string ݇

ᴅllvm/ADT/StringRef.h (doxygen)឴ݐๅמ௳

఍உፗളֵአStringRefᔄ҅ࢩԅ۱ތ೰ݻ᮱ٖጱ೰ᰒ҅ؙᧆ

ᔄጱֺ᭗ଉฎӧقጱҁᴻᶋ఍Ꭳ᭲᮱ؙӧտᤩ᯽න҂

StringRefࣁLLVMӾฎᘒฦ᭭ጱ҅ଫᧆতᕣฎೲ꧊փ᭓

Twineᔄᔄ

Twine (doxygen) ᔄAPI๶᧔ฎӞᐿളݑᬳളᒧԀጱํපොୗ ֺ

ই҅ӞӻଉᥠጱLLVM᝜ֺฎ໑ഝٍํݸᖗጱݚӞӻ೰եጱݷᑍ޸ݷӞӻ

೰եֺ҅ইғ

ᔿྋᘉᦲᔿྋᘉᦲ

New = CmpInst::Create(..., SO->getName() + ".cmp");

The Twine class is effectively a lightweight rope which points to

temporary (stack allocated) objects. Twines can be implicitly

constructed as the result of the plus operator applied to strings (i.e.,

a C strings, an std::string, or a StringRef). The twine delays the

actual concatenation of strings until it is actually required, at which

point it can be efficiently rendered directly into a character array.

This avoids unnecessary heap allocation involved in constructing the

temporary results of string concatenation.

See llvm/ADT/Twine.h (doxygen) and here for more information.

New = CmpInst::Create(..., SO->getName() + ".cmp");

TwineᔄᴬӤฎ೰ݻԁ෸ҁ຾ړᯈ҂᨝ጱ󰪘ᰁᕆropeҁᦲဳғrope

ԅӞᐿහഝᕮ຅҂ ֢ԅଫአԭᒧԀጱےݩᬩᓒᒧҁܨCᒧԀ҅std

:: string౲StringRef҂ጱᕮຎ҅ݢզᵌୗ຅᭜Twines twineݢզ୊᬴

ᒧԀጱᴬᬳളፗکժᴬᵱᥝ෸҅ྌ෸ݢզፗളํපࣈ჉ວک

ᒧහᕟӾ ᬯ᭿عԧ຅ୌᒧԀᬳളጱԁ෸ᕮຎ෸ၿ݊ጱӧ஠ᥝጱړ

ᯈ ᧗݇ᴅllvm/ADT/Twine.h (doxygen)҅ᬯ᯾ํๅጱמ௳

ᔿྋᘉᦲᔿྋᘉᦲ

As with a StringRef, Twine objects point to external memory and

should almost never be stored or mentioned directly. They are

ӨStringRefӞ໏҅Twine᨝೰ݻ᮱ٖ҅پԒӧտፗളؙ౲൉

݊ ժՐአԭԎଫᧆᚆํපളතᬳളᒧԀጱڍහ

ᔿྋᘉᦲᔿྋᘉᦲ

2017/5/17 Ӥ܌9)50LLVM ᑕଧާಋٙ —— LLVM 4.0 ෈໩ - ݢᦲᗑ

ᒫ 4 ᶭҁو 41 ᶭ҂https://coyee.com/article/compare/10594-llvm-programmer-s-manual-llvm-4-0-documentation

intended solely for use when defining a function which should be

able to efficiently accept concatenated strings.

Error handling

Proper error handling helps us identify bugs in our code, and helps

end-users understand errors in their tool usage. Errors fall into two

broad categories: programmatic and recoverable, with different

strategies for handling and reporting.

Programmatic Errors

Programmatic errors are violations of program invariants or API

contracts, and represent bugs within the program itself. Our aim is to

document invariants, and to abort quickly at the point of failure

(providing some basic diagnostic) when invariants are broken at

runtime.

Კ᧏ቘᲙ᧏ቘ

ྋᏟጱᲙ᧏ቘํۗԭ౯ժᦩڦդᎱӾጱᲙ᧏҅ଚଆ๋ۗᕣአಁԧᥴٌ

ૡֵٍአӾጱᲙ᧏ Კ᧏ړԅӷᔄғ

ᖫᑕ௔

ݢ௩௔

҅ժٍํӧ

ݶጱቘ޾ಸޞᒽኼ

ᖫᑕ௔Კ᧏ᖫᑕ௔Კ᧏

ᖫᑕ௔Კ᧏ฎᬲݍᑕଧጱӧݒᰁ౲APIᕅ҅ଚᤒሿࣁᑕଧ๜󰩾ࣁᲙ

᧏ ౯ժጱፓጱฎᦕ୯ӧݒᰁ҅ଚӬ୮ᬩᤈ෸ӧݒᰁݎኞදݒ෸҅ࣁඳ

ᵑᅩҁ൉׀ӞԶ๜᦬ෙ҂ள᭛Ӿෙ

The fundamental tools for handling programmatic errors are

assertions and the llvm_unreachable function. Assertions are used to

express invariant conditions, and should include a message

describing the invariant:

The llvm_unreachable function can be used to document areas of

control flow that should never be entered if the program invariants

hold:

enum { Foo, Bar, Baz } X = foo();

switch (X) {

case Foo: /* Handle Foo */; break;

case Bar: /* Handle Bar */; break;

default:

llvm_unreachable("X should be Foo or Bar here");

}

ቘᖫᑕᲙ᧏ጱ๜ૡٍฎෙ᥺޾llvm_unreachableڍහ ෙ᥺አԭᤒ

ᐏӧݒ๵կ҅ଚଫ۱ೡൈᬿӧݒᰁጱၾ௳ғ

llvm_unreachableڍහݢአԭᦕ୯ᮎԶӧଫᧆᤩᬰفҁইຎᑕଧӧݒᰁ

ތํ҂ጱഴګၞᑕ܄ғ

enum { Foo, Bar, Baz } X = foo();

switch (X) {

case Foo: /* Handle Foo */; break;

case Bar: /* Handle Bar */; break;

default:

llvm_unreachable("X should be Foo or Bar here");

}

ᔿྋᘉᦲᔿྋᘉᦲ

Recoverable Errors

Recoverable errors represent an error in the program’s environment,

for example a resource failure (a missing file, a dropped network

connection, etc.), or malformed input. These errors should be

detected and communicated to a level of the program where they

can be handled appropriately. Handling the error may be as simple as

reporting the issue to the user, or it may involve attempts at recovery.

Recoverable errors are modeled using LLVM’s Error scheme. This

scheme represents errors using function return values, similar to

classic C integer error codes, or C++’s std::error_code. However,

the Error class is actually a lightweight wrapper for user-defined

error types, allowing arbitrary information to be attached to describe

the error. This is similar to the way C++ exceptions allow throwing of

user-defined types.

ݢ௩ጱᲙ᧏ݢ௩ጱᲙ᧏

ݢ௩ጱᲙ᧏ᤒᐏᑕଧሾӾጱᲙ᧏ֺ҅ইᩒრඳᵑҁᗌ෈կ҅Ӷ୒

ጱᗑᕶᬳളᒵ҂౲໒ୗᲙ᧏ጱᬌف ଫᧆ༄ၥᬯԶᲙ᧏ଚٌփ᭓کᖫ

ᑕᕆڦ҅զ׎՜ժ஑کᭇ୮ጱቘቘᲙ᧏ݢզ؟ݻአಁಸޞᳯ󰵭Ӟ

໏ᓌܔ҅Ԟݢᚆၿ݊ᦶ௩

ݢ௩ጱᲙ᧏ֵአLLVMጱᲙ᧏ҁError҂ොໜᬰᤈୌཛྷ ᧆොໜᤒᐏֵ

አڍහᬬࢧ꧊ጱᲙ᧏҅ᔄ֒ԭᕪَጱCෆහᲙ᧏դᎱ҅౲C++ጱstd ::

error_code ֕ฎ҅Error ᔄᴬӤฎአಁԎጱᲙ᧏ᔄࣳጱ󰪘ᰁᕆ۱

ᤰ҅꧋ᦜᴫےձ఺מ௳๶ൈᬿᲙ᧏ ᬯӨC++୑ଉ꧋ᦜಲڊአಁᛔԎ

ᔄࣳጱොୗᔄ֒

ᔿྋᘉᦲᔿྋᘉᦲ

Success values are created by calling Error::success():

Error foo() {

// Do something.

// Return success.

return Error::success();

}

Success values are very cheap to construct and return - they have

minimal impact on program performance.

Failure values are constructed using make_error<T>, where T is any

class that inherits from the ErrorInfo utility:

᭗ᬦ᧣አError :: successҁ҂ڠୌsuccess꧊ғ

Error foo() {

// Do something.

// Return success.

return Error::success();

}

Success꧊ԭ຅ୌ޾ᬬࢧጱ୏ᲀஉ - ժᑕଧ௔ᚆ୽ߥ๋

Failure꧊ֵአmake_error <T>຅ୌٌ҅ӾTฎ՗ErrorInfoአᑕଧᖀಥ

ጱձ֜ᔄғ

ᔿྋᘉᦲᔿྋᘉᦲ

assert(isPhysReg(R) && "All virt regs should have been allocated already."

class MyError : public ErrorInfo<MyError> {

public:

MyError(std::string Msg) : Msg(Msg) {}

void log(OStream &OS) const override { OS << "MyError - "

static char ID;

private:

std::string Msg;

};

char MyError::ID = 0; // In MyError.cpp

Error bar() {

class MyError : public ErrorInfo<MyError> {

public:

MyError(std::string Msg) : Msg(Msg) {}

void log(OStream &OS) const override { OS << "MyError - "

static char ID;

private:

std::string Msg;

};

char MyError::ID = 0; // In MyError.cpp

Error bar() {

if (checkErrorCondition)

return make_error<MyError>("Error condition detected"

2017/5/17 Ӥ܌9)50LLVM ᑕଧާಋٙ —— LLVM 4.0 ෈໩ - ݢᦲᗑ

ᒫ 5 ᶭҁو 41 ᶭ҂https://coyee.com/article/compare/10594-llvm-programmer-s-manual-llvm-4-0-documentation

Error values can be implicitly converted to bool: true for error, false

for success, enabling the following idiom:

Error mayFail();

Error foo() {

if (auto Err = mayFail())

return Err;

// Success! We can proceed.

...

For functions that can fail but need to return a value

the Expected<T> utility can be used. Values of this type can be

constructed with either a T, or a Error. Expected<T> values are also

implicitly convertible to boolean, but with the opposite convention to

Error: true for success, false for error. If success, the T value can be

accessed via the dereference operator. If failure, the Error value can

be extracted using the takeError() method. Idiomatic usage looks

like:

Error꧊ݢզᵌୗ󰪉ഘԅboolғtrueԅerror҅falseԅsuccess҅ԟబֵአ

զӥොୗғ

Error mayFail();

Error foo() {

if (auto Err = mayFail())

return Err;

// Success! We can proceed.

...

ԭݢᚆᨳ֕ᵱᥝᬬࢧ꧊ጱۑᚆ҅ݢզֵአExpected <T>አᑕଧ

ᬯᐿᔄࣳጱ꧊ݢզአT౲ᘏError๶຅᭜ ᶼ๗ጱ<T>꧊Ԟݢզᵌୗ󰪉ഘ

ԅ૲꧊҅֕ӨErrorጱᕅፘݍғtrueአԭsuccess҅falseԅerrorই

ຎ౮ۑ҅ݢզ᭗ᬦᥴ୚አᬩᓒᒧᦢᳯT꧊ ইຎᨳ҅ڞݢզֵአ

takeError()ොဩ൉ݐᲙ᧏꧊ ԟబአဩইӥғ

ᔿྋᘉᦲᔿྋᘉᦲ

Expected<float> parseAndSquareRoot(IStream &IS) {

float f;

OS >> f;

if (f < 0)

return make_error<FloatingPointError>(...);

return sqrt(f);

}

Error foo(IStream &IS) {

if (auto SqrtOrErr = parseAndSquartRoot(IS)) {

float Sqrt = *SqrtOrErr;

// ...

} else

return SqrtOrErr.takeError();

}

All Error instances, whether success or failure, must be either

checked or moved from (via std::move or a return) before they are

destructed. Accidentally discarding an unchecked error will cause a

program abort at the point where the unchecked value’s destructor is

run, making it easy to identify and fix violations of this rule.

Expected<float> parseAndSquareRoot(IStream &IS) {

float f;

OS >> f;

if (f < 0)

return make_error<FloatingPointError>(...);

return sqrt(f);

}

Error foo(IStream &IS) {

if (auto SqrtOrErr = parseAndSquartRoot(IS)) {

float Sqrt = *SqrtOrErr;

// ...

} else

return SqrtOrErr.takeError();

}

ಅํError ֺҁ෫ᦞ౮ۑ౲ᨳ҂҅᮷஠ᶳࣁᤩᲀྪԏڹҁ᭗ᬦstd ::

move౲return҂༄ັ౲ᑏۖ ఺Ӷ୒๚ᕪ༄ັጱᲙ᧏ᛘᑕଧࣁ๚

༄ັ꧊ጱຉ຅ڍහᬩᤈጱࣈොӾྊ҅՗ᘒฃԭᦩڦ޾ץᬲݍྌᥢڞጱ

ᤈԅ

ᔿྋᘉᦲᔿྋᘉᦲ

Success values are considered checked once they have been tested

(by invoking the boolean conversion operator):

In contrast, the following code will always cause an abort, regardless

of the return value of foo:

Failure values are considered checked once a handler for the error

type has been activated:

Success ꧊Ӟ෮ᤩၥᦶݸᦊԅฎᕪᬦ༄ັጱҁ᭗ᬦ᧣አ૲󰪉ഘᬩᓒ

ᒧ҂ғ

ፘݍ҅զӥդᎱ௛ฎᛘӾྊ҅෫ᦞfooጱᬬࢧ꧊ই֜ғ

Ӟ෮Კ᧏ᔄࣳጱቘᑕଧᤩᄶၚ҅տᘍᡤ༄ັFailure ꧊ғ

ᔿྋᘉᦲᔿྋᘉᦲ

if (checkErrorCondition)

return make_error<MyError>("Error condition detected"

// No error - proceed with bar.

// Return success value.

return Error::success();

}

// No error - proceed with bar.

// Return success value.

return Error::success();

}

if (auto Err = canFail(...))

return Err; // Failure value - move error to caller.

// Safe to continue: Err was checked.

canFail();

// Program will always abort here, even if canFail() returns Success, since

// the value is not checked.

auto Err = canFail(...);

if (auto Err2 =

handleErrors(std::move(Err),

[](std::unique_ptr<MyError> M) {

// Try to handle 'M'. If successful, return a success value from

// the handler.

if (tryToHandle(M))

return Error::success();

// We failed to handle 'M' - return it from the handler.

// This value will be passed back from catchErrors and

// wind up in Err2, where it will be returned from this function.

return Error(std::move(M));

})))

return Err2;

if (auto Err = canFail(...))

return Err; // Failure value - move error to caller.

// Safe to continue: Err was checked.

canFail();

// Program will always abort here, even if canFail() returns Success, since

// the value is not checked.

auto Err = canFail(...);

if (auto Err2 =

handleErrors(std::move(Err),

[](std::unique_ptr<MyError> M) {

// Try to handle 'M'. If successful, return a success value from

// the handler.

if (tryToHandle(M))

return Error::success();

// We failed to handle 'M' - return it from the handler.

// This value will be passed back from catchErrors and

// wind up in Err2, where it will be returned from this function.

return Error(std::move(M));

})))

return Err2;

剩余40页未读，继续阅读

wobuhuihuang

粉丝: 0
资源: 5

会员权益专享

LLVM 程序员手册 —— LLVM 4.0 文档 - 可译网

评论0

会员权益专享

最新资源

LLVM 程序员手册 —— LLVM 4.0 文档 - 可译网

评论0

LLVM Cookbook（高清非打印完整版）

方舟编译器工具openarkcompiler - clang+llvm-8.0.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz1

编译器设计第二版

虚拟机linux系统是下载这个包吗： clang+llvm-14.0.0-x86_64-linux-gnu-ubuntu-18.04.tar.xz ？

clang: error: no such file or directory: llvm-config --cxxflags --ldflags --system-libs --libs core

怎么安装这个包clang+llvm-14.0.0-x86_64-linux-gnu-ubuntu-18.04.tar.xz

winlibs-x86_64-posix-seh-gcc-13.2.0-llvm-16.0.6-mingw-w64msvcrt-11.0.1-r1.zi

解压 clang+llvm-14.0.0-x86_64-linux-gnu-ubuntu-18.04.tar.xz 文件后用clang --version读取不到版本号

链接LLVM pass需要用clang -Xclang -load -Xclang特殊形式加载，这样直接链接不起作用的

clang+llvm-8.0.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz

clang+llvm-10.0.0-x86_64-linux-gnu-ubuntu-18.04.tar.xz.sig包

解压tar -xf clang+llvm-14.0.0-x86_64-linux-gnu-ubuntu-18.04.tar.xz之后的安装命令是什么？

错误：软件包：postgresql11-devel-11.20-1PGDG.rhel7.x86_64 (pgdg11) 需要：llvm-toolset-7-clang >= 4.0.1

我在下载了clang+llvm-11.0.0-armv7a-linux-gnueabihf.tar.xz 之后 解压它为clang+llvm-11.0.0 ，但是里边并没有可执行文件，我的路径为/home/kkst/Documents/clang_format

llvm-11.0.0-win64.exe

llvm测试套件在x86交叉编译arm

llvm-objdump -T

Ubuntu 20.04 升级 llvm 版本

llvm-12.0.1-2.module_el8.5.0+918+ed335b90.x86_64 已安装

如何出来llvm-config命令

会员权益专享

最新资源

我在下载了clang+llvm-11.0.0-armv7a-linux-gnueabihf.tar.xz 之后解压它为clang+llvm-11.0.0 ，但是里边并没有可执行文件，我的路径为/home/kkst/Documents/clang_format