Searched refs:our (Results 1 – 25 of 969) sorted by relevance
12345678910>>...39
| /external/llvm/docs/tutorial/ |
| D | BuildingAJIT1.rst | 35 - `Chapter #4 <BuildingAJIT4.html>`_: Improve the laziness of our JIT by
43 To provide input for our JIT we will use the Kaleidoscope REPL from
46 code for that chapter and replace it with optimization support in our JIT class
61 compiler does. To support that aim our initial, bare-bones JIT API will be:
92 In the previous section we described our API, now we examine a simple
96 input for our JIT: Each time the user enters an expression the REPL will add a
99 use the findSymbol method of our JIT class find and execute the code for the
102 of this tutorial we'll modify the REPL to enable new interactions with our JIT
103 class, but for now we will take this setup for granted and focus our attention on
104 the implementation of our JIT itself.
[all …]
|
| D | LangImpl09.rst | 28 our program down to something small and standalone. As part of this
73 First we make our anonymous function that contains our top level
74 statement be our "main":
147 our piece of Kaleidoscope language down to an executable program via this
162 construct one for our fib.ks file.
176 of our IR level descriptions. Construction for it takes a module so we
177 need to construct it shortly after we construct our module. We've left it
180 Next we're going to create a small container to cache some of our frequent
181 data. The first will be our compile unit, but we'll also write a bit of
182 code for our one type since we won't have to worry about multiple typed
[all …]
|
| D | BuildingAJIT2.rst | 36 added to it. In this Chapter we will make optimization a phase of our JIT
38 layers, but in the long term making optimization part of our JIT will yield an
41 optimization managed by our JIT will allow us to optimize lazily too, rather
42 than having to do all our optimization up-front.
44 To add optimization support to our JIT we will take the KaleidoscopeJIT from
79 but after the CompileLayer we introduce a typedef for our optimization function.
82 our optimization function typedef in place we can declare our OptimizeLayer,
83 which sits on top of our CompileLayer.
85 To initialize our OptimizeLayer we pass it a reference to the CompileLayer
122 OptimizeLayer in our key methods: addModule, findSymbol, and removeModule. In
[all …]
|
| D | LangImpl08.rst | 12 <index.html>`_" tutorial. This chapter describes how to compile our
28 As an example, we can see what clang thinks is our current target
64 We can now use our target triple to get a ``Target``:
108 For our example, we'll use the generic CPU without any additional
124 We're now ready to configure our module, to specify the target and
139 our file to:
171 Does it work? Let's give it a try. We need to compile our code, but
189 link it with our output. Here's the source code:
203 We link our program to output.o and check the result is what we
|
| D | LangImpl02.rst | 14 `parser <http://en.wikipedia.org/wiki/Parsing>`_ for our Kaleidoscope
99 expressions. One thing that is nice about our AST is that it captures
104 For our basic language, these are all of the expression nodes we'll
173 in our parser will assume that CurTok is the current token that needs to
189 The ``LogError`` routines are simple helper routines that our parser will
190 use to handle errors. The error recovery in our parser will not be the
191 best and is not particular user-friendly, but it will be enough for our
196 our grammar: numeric literals.
202 process. For each production in our grammar, we'll define a function
249 they happened: in our parser, we return null on an error.
[all …]
|
| /external/curl/tests/data/ |
| 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
|
| D | test1081 | 41 http://%HOSTIP:%HTTPPORT/we/want/our/1081 http://%HOSTIP:%HTTPPORT/we/want/our/10810002 -w '%{redir…
51 GET /we/want/our/1081 HTTP/1.1
55 GET /we/want/our/10810002 HTTP/1.1
67 http://%HOSTIP:%HTTPPORT/we/want/our/data/10810099.txt?coolsite=yes
|
| D | test1029 | 33 http://%HOSTIP:%HTTPPORT/we/want/our/1029 -w '%{redirect_url}\n'
43 GET /we/want/our/1029 HTTP/1.1
55 http://%HOSTIP:%HTTPPORT/we/want/our/data/10290002.txt?coolsite=yes
|
| /external/skia/site/dev/testing/ |
| D | index.md | 4 Skia relies heavily on our suite of unit and Golden Master \(GM\) tests, which
5 are served by our Diamond Master \(DM\) test tool, for correctness testing.
6 Tests are executed by our trybots, for every commit, across most of our
16 See the individual subpages for more details on our various test tools.
|
| /external/skia/site/dev/contrib/ |
| D | c++11.md | 4 Skia uses C++11. But as a library, we are technically limited by what our
5 clients support and what our build bots support.
51 Most of our bots are pretty up-to-date: the Windows bots use MSVC 2013, the Mac
53 bots use a recent toolchain from Android (see above), and our Chrome bots use
54 Chrome's toolchains (see above). I'm not exactly sure what our Chrome OS bots
55 are using. They're probably our weak link right now, though problems are rare.
57 I believe our bots' ability to use C++11 matches Mozilla's list nearly identically.
|
| /external/toolchain-utils/binary_search_tool/ndk/ |
| D | README | 37 flavor for arm7, our compiler wrapper won't try to bisect object files meant
48 specific build flavor in our app/build.gradle file:
54 We want to add this under the same "productFlavors" section that our arm7
56 task in our build system. We can use this to build and install an x86-64
57 version of our app.
59 Now we want to change our test_setup.sh script to run our new gradle task:
|
| /external/clang/cmake/modules/ |
| D | ClangConfig.cmake.in | 1 # This file allows users to call find_package(Clang) and pick up our targets.
10 # Provide all our library targets to users.
|
| /external/flatbuffers/ |
| D | CONTRIBUTING.md | 11 copyright to your changes, even after your contribution becomes part of our
16 approved it, but you must do it before we can put your code into our codebase.
27 * Use our code
37 HEAD. This make reviewing the code so much easier, and our history more
|
| /external/swiftshader/third_party/LLVM/docs/HistoricalNotes/ |
| D | 2001-06-20-.NET-Differences.txt | 4 Subject: .NET vs. our VM
6 One significant difference between .NET CLR and our VM is that the CLR
23 compiled by the same compiler, whereas our approach allows us to link and
|
| /external/llvm/docs/HistoricalNotes/ |
| D | 2001-06-20-.NET-Differences.txt | 4 Subject: .NET vs. our VM
6 One significant difference between .NET CLR and our VM is that the CLR
23 compiled by the same compiler, whereas our approach allows us to link and
|
| /external/googletest/googlemock/docs/ |
| D | KnownIssues.md | 19 …ug in our install, but we should at least have documented it or hacked a work-around into our inst…
|
| /external/eigen/cmake/ |
| D | EigenConfigureTesting.cmake | 22 # Overwrite default DartConfiguration.tcl such that ctest can build our unit tests.
23 # Recall that our unit tests are not in the "all" target, so we have to explicitely ask ctest to bu…
|
| /external/ltp/testcases/open_posix_testsuite/ |
| D | README | 22 our choice of portable tools should make this test suite usable on any
37 statements about our coverage of the POSIX specification.
40 open source projects when our test cases revealed bugs in those projects.
51 the only tests formally documented and enabled by our framework, with our
|
| /external/syslinux/gpxe/ |
| D | README | 11 For more detailed information about gPXE, please visit our project
44 To learn more about what to build and how to use gPXE, please visit our
49 Pointers to our project mailing lists are on http://etherboot.org/
|
| /external/libmicrohttpd/doc/chapters/ |
| D | sessions.inc | 4 this is a network protocol, our session mechanism must support having many users with
22 Here, FIXME is the name we chose for our session cookie.
28 cookies. In order to generate a unique cookie, our example creates a random
35 Given this cookie value, we can then set the cookie header in our HTTP response
|
| /external/swiftshader/third_party/PowerVR_SDK/Examples/Intermediate/DisplacementMap/OGLES2/ |
| D | VertShader.vsh | 17 Calculate the displacemnt value by taking the colour value from our texture
24 move the untransformed position along the normal by our displacement
|
| /external/flatbuffers/docs/source/ |
| D | Tutorial.md | 21 Please select your desired language for our quest:
136 the `schema` that defines the template for our monsters:
139 // Example IDL file for our monster's schema.
179 corresponding package/namespace for the generated code. In our example, we have
198 The `Monster` table is the main object in our FlatBuffer. This will be used as
199 the template to store our `orc` monster. We specify some default values for
208 The `Weapon` table is a sub-table used within our FlatBuffer. It is
210 enum. For our `Monster`, it is used to populate a `vector of tables` via the
211 `weapons` field within our `Monster`. It is also the only table referenced by
215 will be the root table for the serialized data. In our case, the root type is
[all …]
|
| /external/eigen/doc/ |
| D | CustomizingEigen_NullaryExpr.dox | 33 This little helper structure will help us to implement our \c makeCirculant function as follows:
37 As usual, our function takes as argument a \c MatrixBase (see this \ref TopicFunctionTakingEigenTyp…
40 Then, we need to implement our \c circulant_functor, which is a straightforward exercise:
44 We are now all set to try our new feature:
|
| /external/webrtc/webrtc/ |
| D | supplement.gypi | 40 # Replace Chromium's LSan suppressions with our own for WebRTC.
49 # Replace Chromium's TSan v2 suppressions with our own for WebRTC.
|
| /external/llvm/test/CodeGen/AArch64/ |
| D | sibling-call.ll | 38 ; This should reuse our stack area for the 42
48 ; Shouldn't be a tail call: we can't use SP+8 because our caller might
60 ; Reuse our area, putting "42" at incoming sp
|
12345678910>>...39