| /external/llvm/docs/tutorial/ |
| D | LangImpl8.rst | 12 LLVM <index.html>`_" tutorial. In chapters 1 through 7, we've built a
19 source that the programmer wrote. In LLVM we generally use a format
23 The short summary of this chapter is that we'll go through the
27 Caveat: For now we can't debug via the JIT, so we'll need to compile
29 we'll make a few modifications to the running of the language and
30 how programs are compiled. This means that we'll have a source file
32 interactive JIT. It does involve a limitation that we can only
36 Here's the sample program we'll be compiling:
54 locations more difficult. In LLVM IR we keep the original source location
61 tutorial we're going to avoid optimization (as you'll see with one of the
[all …]
|
| D | LangImpl5.rst | 18 of "build that compiler", we'll extend Kaleidoscope to have an
30 Before we get going on "how" we add this extension, lets talk about
31 "what" we want. The basic idea is that we want to be able to write this
44 like any other. Since we're using a mostly functional form, we'll have
57 Now that we know what we "want", lets break this down into its
63 The lexer extensions are straightforward. First we add new enum values
71 Once we have that, we recognize the new keywords in the lexer. This is
87 To represent the new expression we add a new AST node for it:
105 Now that we have the relevant tokens coming from the lexer and we have
107 First we define a new parsing function:
[all …]
|
| D | LangImpl6.rst | 12 LLVM <index.html>`_" tutorial. At this point in our tutorial, we now
23 is good or bad. In this tutorial we'll assume that it is okay to use
26 At the end of this tutorial, we'll run through an example Kaleidoscope
33 The "operator overloading" that we will add to Kaleidoscope is more
37 chapter, we will add this capability to Kaleidoscope, which will let the
42 Thus far, the parser we have been implementing uses recursive descent
49 The two specific features we'll add are programmable unary operators
80 library in the language itself. In Kaleidoscope, we can implement
110 This just adds lexer support for the unary and binary keywords, like we
112 about our current AST, is that we represent binary operators with full
[all …]
|
| D | LangImpl7.rst | 12 LLVM <index.html>`_" tutorial. In chapters 1 through 6, we've built a
15 journey, we learned some parsing techniques, how to build and represent
51 In this case, we have the variable "X", whose value depends on the path
54 two values. The LLVM IR that we want for this example looks like this:
108 With this in mind, the high-level idea is that we want to make a stack
110 mutable object in a function. To take advantage of this trick, we need
138 above, we could rewrite the example to use the alloca technique to avoid
166 With this, we have discovered a way to handle arbitrary mutable
176 another one: we have now apparently introduced a lot of stack traffic
209 pass is the answer to dealing with mutable variables, and we highly
[all …]
|
| D | LangImpl4.rst | 60 Well, that was easy :). In practice, we recommend always using
113 For Kaleidoscope, we are currently generating functions on the fly, one
115 ultimate optimization experience in this setting, but we also want to
116 catch the easy and quick stuff where possible. As such, we will choose
118 in. If we wanted to make a "static Kaleidoscope compiler", we would use
119 exactly the code we have now, except that we would defer running the
122 In order to get per-function optimizations going, we need to set up a
124 and organize the LLVM optimizations that we want to run. Once we have
125 that, we can add a set of optimizations to run. The code looks like
155 pointer to the ``Module`` to construct itself. Once it is set up, we use
[all …]
|
| D | LangImpl2.rst | 15 language. Once we have a parser, we'll define and build an `Abstract
18 The parser we will build uses a combination of `Recursive Descent
23 the former for everything else). Before we get to parsing though, lets
33 Kaleidoscope, we have expressions, a prototype, and a function object.
52 subclass which we use for numeric literals. The important thing to note
57 Right now we only create the AST, so there are no useful accessor
60 definitions that we'll use in the basic form of the Kaleidoscope
98 For our basic language, these are all of the expression nodes we'll
100 Turing-complete; we'll fix that in a later installment. The two things
101 we need next are a way to talk about the interface to a function, and a
[all …]
|
| D | OCamlLangImpl5.rst | 18 of "build that compiler", we'll extend Kaleidoscope to have an
30 Before we get going on "how" we add this extension, lets talk about
31 "what" we want. The basic idea is that we want to be able to write this
44 like any other. Since we're using a mostly functional form, we'll have
57 Now that we know what we "want", lets break this down into its
63 The lexer extensions are straightforward. First we add new variants for
71 Once we have that, we recognize the new keywords in the lexer. This is
90 To represent the new expression we add a new AST variant for it:
104 Now that we have the relevant tokens coming from the lexer and we have
106 First we define a new parsing function:
[all …]
|
| D | LangImpl3.rst | 28 In order to generate LLVM IR, we want some simple setup to get started.
29 First we define virtual code generation (codegen) methods in each AST
69 The second thing we want is an "Error" method like we used for the
99 With these basics in place, we can start talking about how to generate
101 has been set up to generate code *into* something. For now, we'll assume
102 that this has already been done, and we'll just use it to emit code.
109 First we'll do numeric literals:
134 version of Kaleidoscope, we assume that the variable has already been
139 it. In future chapters, we'll add support for `loop induction
164 that we recursively emit code for the left-hand side of the expression,
[all …]
|
| D | OCamlLangImpl2.rst | 15 Kaleidoscope language. Once we have a parser, we'll define and build an
19 The parser we will build uses a combination of `Recursive Descent
24 the former for everything else). Before we get to parsing though, lets
34 Kaleidoscope, we have expressions, a prototype, and a function object.
45 subclass which we use for numeric literals. The important thing to note
50 Right now we only create the AST, so there are no useful functions on
53 we'll use in the basic form of the Kaleidoscope language:
74 For our basic language, these are all of the expression nodes we'll
76 Turing-complete; we'll fix that in a later installment. The two things
77 we need next are a way to talk about the interface to a function, and a
[all …]
|
| /external/llvm/docs/HistoricalNotes/ |
| D | 2003-06-25-Reoptimizer1.txt | 14 exceeds a threshold, we identify a hot loop and perform second-level
30 How do we keep track of which edges to instrument, and which edges are
41 3) Mark BBs which end in edges that exit the hot region; we need to
44 Assume that there is 1 free register. On SPARC we use %g1, which LLC
46 edge which corresponds to a conditional branch, we shift 0 for not
48 through the hot region. Silently fail if we need more than 64 bits.
50 At the end BB we call countPath and increment the counter based on %g1
56 together to form our trace. But we do not allow more than 5 paths; if
57 we have more than 5 we take the ones that are executed the most. We
58 verify our assumption that we picked a hot back-edge in first-level
[all …]
|
| D | 2000-11-18-EarlyDesignIdeasResp.txt | 6 Okay... here are a few of my thoughts on this (it's good to know that we
9 > 1. We need to be clear on our goals for the VM. Do we want to emphasize
10 > portability and safety like the Java VM? Or shall we focus on the
21 pretty expensive operation to have to do. Additionally, we would like
25 2. Instead, we can do the following (eventually):
27 reinventing something that we don't add much value to). When the
36 we could sign the generated VM code with a host specific private
37 key. Then before the code is executed/loaded, we can check to see if
47 3. By focusing on a more low level virtual machine, we have much more room
52 > 2. Design issues to consider (an initial list that we should continue
[all …]
|
| D | 2000-12-06-MeetingSummary.txt | 9 1. We decided that we shall use a flat namespace to represent our
41 idea, we could include an immediate dominator number for each basic block
52 that we will be doing? We know that it has less than stellar
54 static compiler. This could affect us if we decided to do some IP
55 research. Also we do not yet understand the level of exception support
58 2. Should we consider the requirements of a direct hardware implementation
59 of the LLVM when we design it? If so, several design issues should
63 3. Should we use some form of packetized format to improve forward
64 compatibility? For example, we could design the system to encode a
70 4. Should we use fixed length instructions or variable length
[all …]
|
| /external/llvm/docs/ |
| D | MergeFunctions.rst | 22 explains how we could combine equal functions correctly, keeping module valid.
31 cover only common cases, and thus avoid cases when after minor code changes we
39 code fundamentals. In this article we suppose reader is familiar with
77 again and again, and yet you don't understand why we implemented it that way.
98 Do we need to merge functions? Obvious thing is: yes that's a quite possible
99 case, since usually we *do* have duplicates. And it would be good to get rid of
100 them. But how to detect such a duplicates? The idea is next: we split functions
101 onto small bricks (parts), then we compare "bricks" amount, and if it equal,
106 (let's assume we have only one address space), one function stores 64-bit
108 mentioned above, and if functions are identical, except the parameter type (we
[all …]
|
| /external/llvm/test/Transforms/GVN/ |
| D | pre-single-pred.ll | 2 ; This testcase assumed we'll PRE the load into %for.cond, but we don't actually
4 ; %for.end, we would actually be lengthening the execution on some paths, and
5 ; we were never actually checking that case. Now we actually do perform some
6 ; conservative checking to make sure we don't make paths longer, but we don't
7 ; currently get this case, which we got lucky on previously.
9 ; Now that that faulty assumption is corrected, test that we DON'T incorrectly
|
| /external/antlr/antlr-3.4/runtime/ObjC/Framework/examples/simplecTreeParser/ |
| D | main.m | 26 // as we make sure it will not go away.
27 …// If the string would be coming from a volatile source, say a text field, we could opt to copy th…
28 …// That way we could do the parsing in a different thread, and still let the user edit the origina…
29 // But here we do it the simple way.
35 // For fun, you could print all tokens the lexer recognized, but we can only do it once. After that
36 // we would need to reset the lexer, and lex again.
43 // Since the parser needs to scan back and forth over the tokens, we put them into a stream, too.
53 // This is a simple example, so we just call the top-most rule 'program'.
54 // Since we want to parse the AST the parser builds, we just ask the returned object for that.
63 …// tell the TreeNodeStream where the tokens originally came from, so we can retrieve arbitrary tok…
[all …]
|
| /external/eigen/doc/ |
| D | InsideEigenExample.dox | 28 …that is, producing optimized code -- so that the complexity of Eigen, that we'll explain here, is …
39 The problem is that if we make a naive C++ library where the VectorXf class has an operator+ return…
49 Traversing the arrays twice instead of once is terrible for performance, as it means that we do man…
51 …. Notice that Eigen also supports AltiVec and that all the discussion that we make here applies al…
55 …we have chosen size=50, so our vectors consist of 50 float's, and 50 is not a multiple of 4. This …
81 When we do
87 … be stored as a pointer to a dynamically-allocated array. Because of this, we need to abstract sto…
89 …ensions are Dynamic or fixed at compile-time. The partial specialization that we are looking at is:
102 …amically allocated. Rather than calling new[] or malloc(), as you can see, we have our own interna…
104 … m_columns member: indeed, in this partial specialization of DenseStorage, we know the number of c…
[all …]
|
| /external/llvm/test/Transforms/LoopUnroll/ |
| D | full-unroll-heuristics.ll | 1 ; In this test we check how heuristics for complete unrolling work. We have
8 ; * If size of unrolled loop exceeds the absoulte threshold, we don't unroll
10 ; * If size of unrolled loop is below the '-unroll-threshold', then we'll
12 ; * If a loop size is between these two tresholds, we only do complete unroll
13 ; it if estimated number of potentially optimized instructions is high (we
25 ; If the absolute threshold is too low, or if we can't optimize away requested
26 ; percent of instructions, we shouldn't unroll:
30 ; Otherwise, we should:
33 ; Also, we should unroll if the 'unroll-threshold' is big enough:
36 ; And check that we don't crash when we're not allowed to do any analysis.
|
| /external/linux-tools-perf/src/tools/perf/ |
| D | builtin-timechart.c | 409 struct wake_event *we = zalloc(sizeof(*we)); in sched_wakeup() local
411 if (!we) in sched_wakeup()
414 we->time = timestamp; in sched_wakeup()
415 we->waker = pid; in sched_wakeup()
418 we->waker = -1; in sched_wakeup()
420 we->wakee = wake->pid; in sched_wakeup()
421 we->next = wake_events; in sched_wakeup()
422 wake_events = we; in sched_wakeup()
423 p = find_create_pid(we->wakee); in sched_wakeup()
688 struct wake_event *we; in draw_wakeups() local
[all …]
|
| /external/skia/site/user/sample/ |
| D | building.md | 14 I'm going to describe up to the point where we can build a simple application that prints out an Sk…
32 With the remote repo created, we create a .gclient configuration file. The
51 The name that we configured is the directory in which the repo will be checked
66 With the repo created we can go ahead and create our src/DEPS file. The DEPS
86 The `vars` sections defines variables we can use later in the file with the
87 `Var()` accessor. In this case, we define our root directory, a shorter name
88 for any googlecode repositories and a specific revision of Skia that we're
91 the repo they'll be using the same version of Skia that we've built and tested
94 The `deps` section defines our dependencies. Currently we have one dependency
95 which we're going to checkout into the `src/third_party/skia` directory.
[all …]
|
| /external/clang/docs/ |
| D | LibASTMatchersTutorial.rst | 20 repositories, but we'll be accessing them through the git mirror. For
54 Okay. Now we'll build Clang!
66 And we're live.
72 Finally, we want to set Clang as its own compiler.
90 Now that we have enough background knowledge, it's time to create the
95 First, we'll need to create a new directory for our tool and tell CMake
175 Note the two dashes after we specify the source file. The additional
231 Next, we want to specify that a single variable is declared in the first
232 portion of the loop, so we can extend the matcher to
238 Finally, we can add the condition that the variable is initialized to
[all …]
|
| /external/llvm/test/Transforms/PlaceSafepoints/ |
| D | basic.ll | 4 ; Do we insert a simple entry safepoint?
13 ; On a non-gc function, we should NOT get an entry safepoint
21 ; Do we insert a backedge safepoint in a statically
27 ; This statepoint is technically not required, but we don't exploit that yet.
38 ; Check that we remove an unreachable block rather than trying
55 ; Do we turn a call into it's own statepoint
84 ; issues, make sure we don't place safepoints in it.
|
| /external/llvm/test/Other/ |
| D | can-execute.txt | 3 This tests that we abstract two peculiarities of unix in can_execute:
5 * Directories are executable, but we don't want to try to execute them.
6 * For shell scripts, we also need to be able to read them.
13 If we want, it is probably OK to change the semantics of can_execute and this
15 we do that.
|
| /external/chromium-trace/trace-viewer/third_party/WebOb/docs/ |
| D | wiki-example.txt | 37 application we'll be storing the pages under a directory.
48 we'll implement a ``__call__`` method:
55 # what we'll fill in
57 To make the script runnable we'll create a simple command-line
125 For the wiki application we'll support a couple different kinds of
126 screens, and we'll make our ``__call__`` method dispatch to different
137 One last thing we'll do in our ``__call__`` method is create our
153 # Here's where we get the Page domain object:
205 never really be sure. By using ``os.path.normpath`` we eliminate
206 these, and then we make absolutely sure that the resulting path is
[all …]
|
| /external/chromium-trace/trace-viewer/third_party/Paste/docs/ |
| D | do-it-yourself-framework.txt | 27 This isn't an introduction to all the parts of Paste -- in fact, we'll
51 we got here) and ``PATH_INFO`` (what we have left).
115 interactive. To do that we'll give a form, and then parse the form
137 Now, this probably feels a bit crude. After all, we're testing for
142 application. In this tutorial we'll implement an *object publisher*,
150 have to start with some root object, of course, which we'll pass in...
166 applications. Now all we have to do is translate that ``environ``
167 into the thing we are publishing, then call that thing, then turn the
177 the two back together, you get the full path used to get to where we
179 we'll make sure we preserve this.
[all …]
|
| /external/lldb/test/lang/c/forward/ |
| D | README.txt | 3 we have a real declaration for "struct bar". We want to be able to find the
4 real definition of "struct bar" when we are stopped in foo in foo.c such that
5 when we stop in "foo" we see the contents of the "bar_ptr".
|