| /external/tlsdate/ |
| D | HARDENING | 1 Platforms offer varying security features; we'd like to support the best.
3 This is a document that notes which security hardening we have implemented and
4 which things we'd like to see implemented for various platforms. We
12 wrapping because we believe the practical benefit outweights the implied risks.
13 As such, we prefer to be explicit rather than implicit in our casting or other
17 consider autotools warnings to be an exception as we would like to support
22 On all platforms we attempt to support available compiler hardening and linking
29 On all platforms, we attempt to switch from the administrative user to an
30 unimportant role account which shares data with no other processes. If we start
31 as any user other than an administrative user, we will likely be unable to
[all …]
|
| /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 | 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. We'll need a new
126 FunctionPassManager for each module that we want to optimize, so we'll
[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
73 Once we have that, we recognize the new keywords in the lexer. This is
94 To represent the new expression we add a new AST node for it:
114 Now that we have the relevant tokens coming from the lexer and we have
116 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
115 This just adds lexer support for the unary and binary keywords, like we
117 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 | 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.
53 subclass which we use for numeric literals. The important thing to note
58 Right now we only create the AST, so there are no useful accessor
61 definitions that we'll use in the basic form of the Kaleidoscope
104 For our basic language, these are all of the expression nodes we'll
106 Turing-complete; we'll fix that in a later installment. The two things
107 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 …]
|
| /external/tlsdate/m4/ |
| D | ax_platform.m4 | 39 AC_DEFINE([TARGET_OS_WINDOWS], [1], [Whether we are building for Windows])
52 AC_DEFINE([TARGET_OS_MINGW],[1],[Whether we build for MinGW])],
55 AC_DEFINE([TARGET_OS_CYGWIN],[1],[Whether we build for Cygwin])],
58 AC_DEFINE([TARGET_OS_HAIKU],[1],[Whether we build for Haiku])],
61 AC_DEFINE([TARGET_OS_FREEBSD],[1],[Whether we are building for FreeBSD])],
65 AC_DEFINE([TARGET_OS_FREEBSD],[1],[Whether we are building for FreeBSD])
66 AC_DEFINE([TARGET_OS_GNUKFREEBSD],[1],[Whether we are building for GNU/kFreeBSD])],
69 AC_DEFINE([TARGET_OS_NETBSD],[1],[Whether we are building for NetBSD])],
72 AC_DEFINE([TARGET_OS_OPENBSD],[1],[Whether we are building for OpenBSD])],
75 AC_DEFINE([TARGET_OS_DRAGONFLYBSD],[1],[Whether we are building for DragonFly BSD])],
[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/curl/tests/data/ |
| D | test62 | 32 http://%HOSTIP:%HTTPPORT/we/want/62 http://%HOSTIP:%HTTPPORT/we/want?hoge=fuga -b log/jar62.txt -H …
39 #HttpOnly_.foo.com TRUE /we/want/ FALSE 2054030187 test yes
40 .host.foo.com TRUE /we/want/ FALSE 2054030187 test2 yes
41 .fake.host.foo.com TRUE /we/want/ FALSE 2054030187 test4 yes
53 GET /we/want/62 HTTP/1.1
58 GET /we/want?hoge=fuga HTTP/1.1
|
| D | test1080 | 33 http://%HOSTIP:%HTTPPORT/we/want/our/1080 http://%HOSTIP:%HTTPPORT/we/want/our/1080 -w '%{redirect_…
43 GET /we/want/our/1080 HTTP/1.1
47 GET /we/want/our/1080 HTTP/1.1
59 http://%HOSTIP:%HTTPPORT/we/want/our/data/10800002.txt?coolsite=yes
66 http://%HOSTIP:%HTTPPORT/we/want/our/data/10800002.txt?coolsite=yes
|
| /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/autotest/server/site_tests/platform_InstallTestImage/ |
| D | control | 39 # If we're invoked from test_that, the user can pass an
40 # optional "image" argument. If it's omitted, we want to pass
45 # If we're called from the AFE, there won't be an "image"
46 # argument, and we want to ask the dev server to stage a test
49 # To distinguish the two cases above, we ask the host for
50 # the name of the default image we should stage. When we're
51 # called from test_that, this call should fail when we
52 # try to look the host up in the AFE database. Otherwise, if we
53 # get a valid image name, we use it to stage a build.
|
| /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/skia/platform_tools/android/gyp/ |
| D | dependencies.gypi | 8 # distribution so we have to build a few of them ourselves.
69 # shared libraries, we need a common entry point to wrap around main().
70 # Here we also change the type of all would-be executables to be shared
82 # we're guaranteed that '_type' will be defined when we get here.
95 # libraries, we need a common entry point to wrap around main(). Here
96 # we also change the type of all would-be executables to be shared
108 # we're guaranteed that '_type' will be defined when we get here.
124 # libraries, we need a common entry point to wrap around main(). Here
125 # we also change the type of all would-be executables to be shared
137 # we're guaranteed that '_type' will be defined when we get here.
[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/llvm/test/Transforms/IndVarSimplify/ |
| D | loop-invariant-conditions.ll | 37 ; As long as the test dominates the backedge, we're good
50 ; prevent flattening, needed to make sure we're testing what we intend
72 ; prevent flattening, needed to make sure we're testing what we intend
94 ; prevent flattening, needed to make sure we're testing what we intend
116 ; prevent flattening, needed to make sure we're testing what we intend
146 ; Negative test - we can't show that the internal branch executes, so we can't
159 ; prevent flattening, needed to make sure we're testing what we intend
165 ; prevent flattening, needed to make sure we're testing what we intend
188 ; prevent flattening, needed to make sure we're testing what we intend
192 ; prevent flattening, needed to make sure we're testing what we intend
[all …]
|
| /external/autotest/server/control_segments/ |
| D | provision | 33 # Raising a blank exception is done here because any message we can
41 # the special task failed. Therefore we need python to exit because
45 # cleanup) that we'd be skipping out on. So therefore, we need to
46 # raise an exception. However, if we raise an exception, this
49 # up as the reason field for the job when the status.log we generate is
52 # So therefore, we raise a blank exception, which then generates an
54 # a SERVER_JOB failure with no reason, which we then ignore at suite
58 # If we finish successfully, nothing in autotest ever looks at the
|
| /external/autotest/client/site_tests/kernel_Oom/ |
| D | control | 7 Verify that we get low memory notification from /dev/chromeos-low-mem
8 before we kill processes (OOM) when we consume a lot of memory.
14 Fails if we OOM (ie, processes get killed) before we get low memory
|