| /external/chromium_org/third_party/yasm/source/patched-yasm/libyasm/ |
| D | errwarn.c | 194 errwarn_data *first, *next, *ins_we, *we; in errwarn_data_new() local
221 we = ins_we; in errwarn_data_new()
224 we = yasm_xmalloc(sizeof(errwarn_data)); in errwarn_data_new()
226 we->type = WE_UNKNOWN; in errwarn_data_new()
227 we->line = line; in errwarn_data_new()
228 we->xrefline = 0; in errwarn_data_new()
229 we->msg = NULL; in errwarn_data_new()
230 we->xrefmsg = NULL; in errwarn_data_new()
233 SLIST_INSERT_HEAD(&errwarns->errwarns, we, link); in errwarn_data_new()
236 SLIST_INSERT_AFTER(ins_we, we, link); in errwarn_data_new()
[all …]
|
| /external/qemu/distrib/sdl-1.2.15/Xcode/SDL/pkg-support/resources/ |
| D | UniversalBinaryNotes.rtf | 12 …now Leopard on the market. In order to make SDL compile and run in 64-bit, we had to remove code t…
16 Because of all these combined factors, we have made the decision to make Mac OS X 10.4 the new mini…
27 …we had to remove the SDL Custom Cocoa Xcode template project. It depended on NSQuickTimeView which…
33 …(Recall that we also disabled MP3 support awhile back because we never got SMPEG working during th…
35 …we have changed the baseline to 10.4, we took this opportunity to switch SDL_image over to a new n…
37 …we no longer have access to a libfreetype.a. We have been relying on Apple's supplied libfreetype.…
49 …we had to do to build Universal Binaries for SDL (and satellites). The document is provided to hel…
52 …est obstacles. (The only real code bug we had to fix was in SDL_mixer, but that was due to a Quick…
61 …ellites (SDL_mixer, SDL_image, SDL_ttf) have 3rd party dependencies which we currently statically…
64 …we have experimentally determined that there is no reliable way to use gcc 4.0.x to compile a bina…
[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-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 …]
|
| 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 …]
|
| /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/llvm/docs/tutorial/ |
| 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 …]
|
| /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/chromium_org/chrome/browser/ui/cocoa/bookmarks/ |
| D | bookmark_bar_folder_hover_state.mm | 26 // CASE A: hoverButton_ == button implies we've dragged over
30 // CASE B: we have a hoverButton_ but it is different from the new button.
31 // This implies we've dragged over a new folder, so we'll close the old
33 // Note that we only schedule the open or close if we have no other tasks
44 // CASE C: we don't have a current hoverButton_ but we have dragged onto
45 // a new folder so we open the new one.
50 // CASE D: We have a hoverButton_ but we've moved onto an area that
53 // or closing if we don't alrealy have once in progress.
55 // Intiate close only if we have not already done so.
65 // a hover. In this case we do nothing.
|
| D | bookmark_folder_target.mm | 54 // NOTE: we cannot use [[sender cell] mouseDownFlags] because we
56 // draggable. Thus we must use [NSApp currentEvent].
59 // over a bookmark folder) can confuse us. Unless we check the
60 // event type, we are not sure if this is an "open folder" due to a
81 // Else we clicked on a different folder so more work to do.
98 // TODO(viettrungluu): I'm not sure what we should do, so just declare the
99 // "additional" types we're given for now. Maybe we want to add a list of
100 // URLs? Would we then have to recurse if there were subfolders?
101 // In the meanwhile, we *must* set it to a known state.
|
| /external/chromium/chrome/browser/ui/cocoa/bookmarks/ |
| D | bookmark_bar_folder_hover_state.mm | 26 // CASE A: hoverButton_ == button implies we've dragged over
30 // CASE B: we have a hoverButton_ but it is different from the new button.
31 // This implies we've dragged over a new folder, so we'll close the old
33 // Note that we only schedule the open or close if we have no other tasks
44 // CASE C: we don't have a current hoverButton_ but we have dragged onto
45 // a new folder so we open the new one.
50 // CASE D: We have a hoverButton_ but we've moved onto an area that
53 // or closing if we don't alrealy have once in progress.
55 // Intiate close only if we have not already done so.
65 // a hover. In this case we do nothing.
|
| D | bookmark_folder_target.mm | 43 // NOTE: we cannot use [[sender cell] mouseDownFlags] because we
45 // draggable. Thus we must use [NSApp currentEvent].
48 // over a bookmark folder) can confuse us. Unless we check the
49 // event type, we are not sure if this is an "open folder" due to a
70 // Else we clicked on a different folder so more work to do.
87 // TODO(viettrungluu): I'm not sure what we should do, so just declare the
88 // "additional" types we're given for now. Maybe we want to add a list of
89 // URLs? Would we then have to recurse if there were subfolders?
90 // In the meanwhile, we *must* set it to a known state. (If this survives to
|
| /external/linux-tools-perf/ |
| D | builtin-timechart.c | 435 struct wake_event *we; in sched_wakeup() local
439 we = malloc(sizeof(struct wake_event)); in sched_wakeup()
440 if (!we) in sched_wakeup()
443 memset(we, 0, sizeof(struct wake_event)); in sched_wakeup()
444 we->time = timestamp; in sched_wakeup()
445 we->waker = pid; in sched_wakeup()
448 we->waker = -1; in sched_wakeup()
450 we->wakee = wake->pid; in sched_wakeup()
451 we->next = wake_events; in sched_wakeup()
452 wake_events = we; in sched_wakeup()
[all …]
|
| /external/pixman/ |
| D | config.h.in | 6 /* Whether we have alarm() */
12 /* Whether we have feenableexcept() */
15 /* Define to 1 if we have <fenv.h> */
24 /* Whether we have getpagesize() */
27 /* Whether we have gettimeofday() */
36 /* Whether we have libpng */
42 /* Whether we have mmap() */
45 /* Whether we have mprotect() */
48 /* Whether we have posix_memalign() */
54 /* Whether we have sigaction() */
[all …]
|
| /external/chromium_org/third_party/tcmalloc/vendor/ |
| D | configure.ac | 4 # make sure we're interpreted by some minimal autoconf
36 # code as well. By default, we include all of these that the
88 AM_CONDITIONAL(GCC, test "$GCC" = yes) # let the Makefile know if we're gcc
91 # Check if we have an objcopy installed that supports -W
125 # TODO(csilvers): we could remove a lot when WITH_CPU_PROFILER etc is "no".
151 AC_CHECK_HEADERS(valgrind.h) # we have a local copy if this isn't found
154 # We also need <ucontext.h>/<sys/ucontext.h>, but we get those from
158 # standard. For those the system doesn't declare, we'll declare ourselves.
189 # If AtomicWord != Atomic32, we need to define two versions of all the
190 # atomicops functions. If they're the same, we want to define only one.
[all …]
|
| /external/chromium_org/third_party/WebKit/Source/platform/fonts/mac/ |
| D | MemoryActivatedFont.mm | 25 // Because we want to support loading fonts between processes in the face of
26 // font loading being blocked by the sandbox, we need a mechnasim to both
52 // This means that when loading a font we need to round-trip through the browser
53 // process in order to get the unique font file identifer which we might already
56 // In order to save as much work as we can, we maintain 2 levels of caching
58 // 1. A dumb cache keyed by the font name/style (information we can determine
62 // In order to perform a lookup in #2 we need to consult with the browser to get
82 // Given a font specified by |srcFont|, use the information we can query in
83 // the sandbox to construct a key which we hope will be as unique as possible
92 // The only way we can tell that an in-process font has failed to load
[all …]
|
| /external/chromium_org/chrome/browser/background/ |
| D | background_mode_manager_mac.mm | 71 // Call back to the UI thread to set our preference so we know that Chrome
72 // created the login item (which means we are allowed to delete it later).
93 // There are a few cases we need to handle:
99 // already set (meaning that we created a login item that has since been
100 // deleted) then we will set the kUserRemovedLoginItem so we do not create
104 // the kChromeCreatedLoginItem flag is false, we do nothing. Otherwise, we
105 // will delete the login item if it's present, and not we will set
116 // If we previously created a login item, we don't need to create
117 // a new one - just check to see if the user removed it so we don't
136 // Clear the pref now that we're removing the login item.
[all …]
|
| /external/eigen/doc/ |
| D | I03_InsideEigenExample.dox | 33 …that is, producing optimized code -- so that the complexity of Eigen, that we'll explain here, is …
44 The problem is that if we make a naive C++ library where the VectorXf class has an operator+ return…
54 Traversing the arrays twice instead of once is terrible for performance, as it means that we do man…
56 …. Notice that Eigen also supports AltiVec and that all the discussion that we make here applies al…
60 …we have chosen size=50, so our vectors consist of 50 float's, and 50 is not a multiple of 4. This …
86 When we do
92 … be stored as a pointer to a dynamically-allocated array. Because of this, we need to abstract sto…
94 …ensions are Dynamic or fixed at compile-time. The partial specialization that we are looking at is:
107 …amically allocated. Rather than calling new[] or malloc(), as you can see, we have our own interna…
109 … m_columns member: indeed, in this partial specialization of DenseStorage, we know the number of c…
[all …]
|
| /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/protobuf/m4/ |
| D | stl_hash.m4 | 3 # include AC_TRY_COMPILE for all the combinations we've seen in the
8 # Ideally we'd use AC_CACHE_CHECK, but that only lets us store one value
9 # at a time, and we need to store two (filename and namespace).
10 # prints messages itself, so we have to do the message-printing ourselves
11 # via AC_MSG_CHECKING + AC_MSG_RESULT. (TODO(csilvers): can we cache?)
26 # calling find() on a const unordered_map does not compile. So, we
29 # fine on this platform, so we'll end up using that.
|
| /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
171 Note the two dashes after we specify the source file. The additional
227 Next, we want to specify that a single variable is declared in the first
228 portion of the loop, so we can extend the matcher to
234 Finally, we can add the condition that the variable is initialized to
[all …]
|