Home
last modified time | relevance | path

Searched refs:accesses (Results 1 – 25 of 438) sorted by relevance

12345678910>>...18

/external/compiler-rt/lib/tsan/rtl/
Dtsan_flags.inc42 "Report races between atomic and plain memory accesses.")
66 "Per-thread history size, controls how many previous memory accesses "
68 "history_size=0 amounts to 32K memory accesses. Each next value doubles "
69 "the amount of memory accesses, up to history_size=7 that amounts to "
70 "4M memory accesses. The default value is 2 (128K memory accesses).")
/external/v8/tools/clang/blink_gc_plugin/tests/
Ddestructor_access_finalized_field.txt1 destructor_access_finalized_field.cpp:18:9: warning: [blink-gc] Finalizer '~HeapObject' accesses po…
7 destructor_access_finalized_field.cpp:19:5: warning: [blink-gc] Finalizer '~HeapObject' accesses po…
13 destructor_access_finalized_field.cpp:20:5: warning: [blink-gc] Finalizer '~HeapObject' accesses po…
Ddestructor_eagerly_finalized.txt1 …cpp:26:5: warning: [blink-gc] Finalizer '~HeapObjectEagerFinalizedAlso' accesses eagerly finalized…
7 …cpp:27:5: warning: [blink-gc] Finalizer '~HeapObjectEagerFinalizedAlso' accesses eagerly finalized…
/external/u-boot/doc/
DREADME.unaligned-memory-access.txt9 unaligned accesses, why you need to write code that doesn't cause them,
16 Unaligned memory accesses occur when you try to read N bytes of data starting
53 - Some architectures are able to perform unaligned memory accesses
55 - Some architectures raise processor exceptions when unaligned accesses
58 - Some architectures raise processor exceptions when unaligned accesses
66 memory accesses to happen, your code will not work correctly on certain
97 to pad structures so that accesses to fields are suitably aligned (assuming
130 lead to unaligned accesses when accessing fields that do not satisfy
177 Here is another example of some code that could cause unaligned accesses:
185 This code will cause unaligned accesses every time the data parameter points
[all …]
DREADME.fsl_iim28 Read operations are implemented as read accesses to the shadow registers,
42 Override operations are implemented as write accesses to the shadow
DREADME.mxc_ocotp31 Read operations are implemented as read accesses to the shadow registers,
45 Override operations are implemented as write accesses to the shadow
/external/swiftshader/third_party/llvm-7.0/llvm/test/CodeGen/SystemZ/
Dunaligned-01.ll1 ; Check that unaligned accesses are allowed in general. We check the
22 ; Check that unaligned 2-byte accesses are allowed.
33 ; Check that unaligned 4-byte accesses are allowed.
47 ; Check that unaligned 8-byte accesses are allowed.
/external/llvm/test/CodeGen/SystemZ/
Dunaligned-01.ll1 ; Check that unaligned accesses are allowed in general. We check the
25 ; Check that unaligned 2-byte accesses are allowed.
36 ; Check that unaligned 4-byte accesses are allowed.
50 ; Check that unaligned 8-byte accesses are allowed.
/external/llvm/test/CodeGen/X86/
Dslow-unaligned-mem.ll1 ; Intel chips with slow unaligned memory accesses
15 ; Intel chips with fast unaligned memory accesses
27 ; AMD chips with slow unaligned memory accesses
39 ; AMD chips with fast unaligned memory accesses
50 ; Other chips with slow unaligned memory accesses
58 ; Also verify that SSE4.2 or SSE4a imply fast unaligned accesses.
/external/swiftshader/third_party/llvm-7.0/llvm/test/CodeGen/X86/
Dslow-unaligned-mem.ll1 ; Intel chips with slow unaligned memory accesses
15 ; Intel chips with fast unaligned memory accesses
27 ; AMD chips with slow unaligned memory accesses
39 ; AMD chips with fast unaligned memory accesses
51 ; Other chips with slow unaligned memory accesses
59 ; Also verify that SSE4.2 or SSE4a imply fast unaligned accesses.
/external/swiftshader/third_party/llvm-7.0/llvm/test/Analysis/LoopAccessAnalysis/
Dmemcheck-wrapping-pointers.ll1 ; RUN: opt -basicaa -loop-accesses -analyze < %s | FileCheck %s
11 ; If accesses to a and b can alias, we need to emit a run-time alias check
12 ; between accesses to a and b. However, when i and i + 1 can wrap, their
17 ; The accesses at b[i] and a[i+1] correspond to the addresses %arrayidx and
35 ; CHECK-NEXT: Grouped accesses:
Dnullptr.ll1 ; RUN: opt -loop-accesses -analyze %s | FileCheck %s
4 ; Test that the loop accesses are proven safe in this case.
Dindependent-interleaved.ll1 ; RUN: opt < %s -store-to-load-forwarding-conflict-detection=false -loop-accesses -analyze | FileCh…
4 ; This test checks that we prove the strided accesses to be independent before
Dpr31098.ll1 ; RUN: opt -loop-accesses -analyze < %s | FileCheck %s
7 ; statically. Due to the non-unit stride of the accesses in this testcase
12 ; dependence distances between the 8 real/imaginary accesses below:
Dnumber-of-memchecks.ll1 ; RUN: opt -loop-accesses -analyze < %s | FileCheck %s
63 ; memory checks of accesses which differ by a constant value.
97 ; CHECK-NEXT: Grouped accesses:
152 ; accesses, so we cannot overflow the GEPs.
169 ; CHECK-NEXT: Grouped accesses:
248 ; CHECK-NEXT: Grouped accesses:
Dmemcheck-off-by-one-error.ll1 ; RUN: opt -analyze --loop-accesses %s | FileCheck %s
3 ; This test verifies run-time boundary check of memory accesses.
/external/swiftshader/third_party/llvm-7.0/llvm/test/Transforms/LoopVectorize/
Dpr31098.ll2 …dth=4 -force-vector-interleave=1 -enable-interleaved-mem-accesses=true -debug-only=loop-accesses <…
7 ; statically. Due to the non-unit stride of the accesses in this testcase
12 ; dependence distances between the 8 real/imaginary accesses below:
/external/selinux/python/sepolgen/src/sepolgen/
Daudit.py180 self.accesses = []
200 self.accesses.append(recs[i])
255 access_tuple = tuple( self.accesses)
261 self.type, self.data = audit2why.analyze(scontext, tcontext, self.tclass, self.accesses)
271 raise ValueError("Invalid permission %s\n" % " ".join(self.accesses))
535 avc.tclass] + avc.accesses)
/external/selinux/python/sepolgen/tests/
Dtest_audit.py78 self.assertEqual(avc.accesses, [])
96 self.assertEqual(avc.accesses, ["getattr"])
142 self.assertEqual(avc.accesses, ["read"])
166 self.assertEqual(avc.accesses, ["dac_read_search"])
/external/mesa3d/src/gallium/drivers/vc4/
Dvc4_qpu.c270 int accesses = 0; in qpu_num_sf_accesses() local
295 accesses++; in qpu_num_sf_accesses()
297 accesses++; in qpu_num_sf_accesses()
301 accesses++; in qpu_num_sf_accesses()
304 accesses++; in qpu_num_sf_accesses()
312 accesses++; in qpu_num_sf_accesses()
315 return accesses; in qpu_num_sf_accesses()
/external/swiftshader/third_party/llvm-7.0/llvm/test/Transforms/LoadStoreVectorizer/X86/
Dmerge-tbaa.ll4 ; The GPU Load & Store Vectorizer may merge differently-typed accesses into a
6 ; accesses correctly.
/external/llvm/test/Analysis/LoopAccessAnalysis/
Dnullptr.ll1 ; RUN: opt -loop-accesses -analyze %s | FileCheck %s
4 ; Test that the loop accesses are proven safe in this case.
Dindependent-interleaved.ll1 ; RUN: opt < %s -store-to-load-forwarding-conflict-detection=false -loop-accesses -analyze | FileCh…
4 ; This test checks that we prove the strided accesses to be independent before
Dnumber-of-memchecks.ll1 ; RUN: opt -loop-accesses -analyze < %s | FileCheck %s
63 ; memory checks of accesses which differ by a constant value.
97 ; CHECK-NEXT: Grouped accesses:
152 ; accesses, so we cannot overflow the GEPs.
169 ; CHECK-NEXT: Grouped accesses:
248 ; CHECK-NEXT: Grouped accesses:
/external/arm-neon-tests/
DInitCache.s33 ;ORR r0, r0, #(0x1 << 4) ;Enables speculative accesses on AXI
34 ORR r0, r0, #(0x1 << 4) ;Enables speculative accesses on AXI

12345678910>>...18