| /external/llvm/unittests/Transforms/Utils/ |
| D | ValueMapperTest.cpp | 27 ValueToValueMapTy VM; in TEST() local
28 EXPECT_EQ(U, ValueMapper(VM).mapMDNode(*U)); in TEST()
54 ValueToValueMapTy VM; in TEST() local
55 EXPECT_EQ(U0, ValueMapper(VM).mapMDNode(*U0)); in TEST()
56 EXPECT_EQ(U1, ValueMapper(VM).mapMDNode(*U1)); in TEST()
61 ValueToValueMapTy VM; in TEST() local
62 EXPECT_EQ(U1, ValueMapper(VM).mapMDNode(*U1)); in TEST()
63 EXPECT_EQ(U0, ValueMapper(VM).mapMDNode(*U0)); in TEST()
95 ValueToValueMapTy VM; in TEST() local
96 VM[G0.get()] = G1.get(); in TEST()
[all …]
|
| /external/swiftshader/third_party/LLVM/unittests/VMCore/ |
| D | ValueMapTest.cpp | 50 ValueMap<TypeParam*, int> VM; in TYPED_TEST() local
51 VM[this->BitcastV.get()] = 7; in TYPED_TEST()
52 EXPECT_EQ(7, VM.lookup(this->BitcastV.get())); in TYPED_TEST()
53 EXPECT_EQ(0, VM.count(this->AddV.get())); in TYPED_TEST()
55 EXPECT_EQ(7, VM.lookup(this->AddV.get())); in TYPED_TEST()
56 EXPECT_EQ(0, VM.count(this->BitcastV.get())); in TYPED_TEST()
58 EXPECT_EQ(0, VM.count(this->AddV.get())); in TYPED_TEST()
59 EXPECT_EQ(0, VM.count(this->BitcastV.get())); in TYPED_TEST()
60 EXPECT_EQ(0U, VM.size()); in TYPED_TEST()
64 ValueMap<TypeParam*, int> VM; in TYPED_TEST() local
[all …]
|
| /external/llvm/unittests/IR/ |
| D | ValueMapTest.cpp | 48 ValueMap<TypeParam*, int> VM; in TYPED_TEST() local
49 VM[this->BitcastV.get()] = 7; in TYPED_TEST()
50 EXPECT_EQ(7, VM.lookup(this->BitcastV.get())); in TYPED_TEST()
51 EXPECT_EQ(0u, VM.count(this->AddV.get())); in TYPED_TEST()
53 EXPECT_EQ(7, VM.lookup(this->AddV.get())); in TYPED_TEST()
54 EXPECT_EQ(0u, VM.count(this->BitcastV.get())); in TYPED_TEST()
56 EXPECT_EQ(0u, VM.count(this->AddV.get())); in TYPED_TEST()
57 EXPECT_EQ(0u, VM.count(this->BitcastV.get())); in TYPED_TEST()
58 EXPECT_EQ(0U, VM.size()); in TYPED_TEST()
62 ValueMap<TypeParam*, int> VM; in TYPED_TEST() local
[all …]
|
| /external/swiftshader/third_party/LLVM/lib/Transforms/Utils/ |
| D | ValueMapper.cpp | 26 Value *llvm::MapValue(const Value *V, ValueToValueMapTy &VM, RemapFlags Flags, in MapValue() argument
28 ValueToValueMapTy::iterator I = VM.find(V); in MapValue()
31 if (I != VM.end() && I->second) return I->second; in MapValue()
36 return VM[V] = const_cast<Value*>(V); in MapValue()
49 return VM[V] = const_cast<Value*>(V); in MapValue()
57 return VM[V] = const_cast<Value*>(V); in MapValue()
61 VM[V] = Dummy; in MapValue()
66 if (OP == 0 || MapValue(OP, VM, Flags, TypeMapper) == OP) continue; in MapValue()
73 Elts.push_back(Op ? MapValue(Op, VM, Flags, TypeMapper) : 0); in MapValue()
77 VM[V] = NewMD; in MapValue()
[all …]
|
| /external/llvm/include/llvm/Transforms/Utils/ |
| D | ValueMapper.h | 142 ValueMapper(ValueToValueMapTy &VM, RemapFlags Flags = RF_None,
152 registerAlternateMappingContext(ValueToValueMapTy &VM,
198 inline Value *MapValue(const Value *V, ValueToValueMapTy &VM,
202 return ValueMapper(VM, Flags, TypeMapper, Materializer).mapValue(*V);
220 inline Metadata *MapMetadata(const Metadata *MD, ValueToValueMapTy &VM,
224 return ValueMapper(VM, Flags, TypeMapper, Materializer).mapMetadata(*MD);
228 inline MDNode *MapMetadata(const MDNode *MD, ValueToValueMapTy &VM,
232 return ValueMapper(VM, Flags, TypeMapper, Materializer).mapMDNode(*MD);
243 inline void RemapInstruction(Instruction *I, ValueToValueMapTy &VM,
247 ValueMapper(VM, Flags, TypeMapper, Materializer).remapInstruction(*I);
[all …]
|
| /external/cros/system_api/dbus/vm_concierge/ |
| D | service.proto | 11 // Specification of the key components of a VM.
13 // Path to the kernel that should be used for the VM.
17 // the VM.
30 // Describes any additional disk images that should be mounted inside the VM.
35 // Path where this disk image will be mounted inside the VM.
58 // Information about a particular VM.
60 // The IPv4 address assigned to the VM, in network byte order.
63 // The process ID of the main crosvm process for the VM.
66 // The virtual socket context id assigned to the VM.
72 // The VM that should be started. This is ignored if starting a termina VM,
[all …]
|
| /external/llvm/docs/HistoricalNotes/ |
| D | 2001-07-06-LoweringIRForCodeGen.txt | 9 VM -- it is a little too specialized. But without a corresponding
10 conditional move instruction in the VM, it is pretty difficult to maintain a
11 close mapping between VM and machine code. Other architectures may have
15 additional VM instructions that match some of the unusual opcodes on the
16 processor but have VM semantics otherwise, i.e., all operands are in SSA
17 form and typed. This means that we can re-generate core VM code from the
20 Typically, a static compiler like gcc would generate just the core VM, which
23 specialized target-specific VM code for a particular architecture. If the
28 mapping between VM and machine code.
|
| D | 2000-11-18-EarlyDesignIdeasResp.txt | 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
18 1. The VM code is NOT guaranteed safe in a java sense. Doing so makes it
31 VM. Performance is not wonderful, but it works right.
36 we could sign the generated VM code with a host specific private
48 for value add. The nice safe "sandbox" VM can be provided as a layer
58 > a. A single-assignment VM, which we've both already been thinking
62 however, by the prospect of a minimally allocated VM representation... I
78 VM). This is the point that disallows java style bytecodes, where all
87 > b. A strongly-typed VM. One question is do we need the types to be
[all …]
|
| D | 2000-11-18-EarlyDesignIdeas.txt | 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
28 a. A single-assignment VM, which we've both already been thinking about.
30 b. A strongly-typed VM. One question is do we need the types to be
33 c. How do we get more high-level information into the VM while keeping
34 to a low-level VM design?
|
| 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
14 advantages to have a much lower level VM layer, and do significant static
|
| /external/swiftshader/third_party/LLVM/docs/HistoricalNotes/ |
| D | 2001-07-06-LoweringIRForCodeGen.txt | 9 VM -- it is a little too specialized. But without a corresponding
10 conditional move instruction in the VM, it is pretty difficult to maintain a
11 close mapping between VM and machine code. Other architectures may have
15 additional VM instructions that match some of the unusual opcodes on the
16 processor but have VM semantics otherwise, i.e., all operands are in SSA
17 form and typed. This means that we can re-generate core VM code from the
20 Typically, a static compiler like gcc would generate just the core VM, which
23 specialized target-specific VM code for a particular architecture. If the
28 mapping between VM and machine code.
|
| D | 2000-11-18-EarlyDesignIdeasResp.txt | 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
18 1. The VM code is NOT guaranteed safe in a java sense. Doing so makes it
31 VM. Performance is not wonderful, but it works right.
36 we could sign the generated VM code with a host specific private
48 for value add. The nice safe "sandbox" VM can be provided as a layer
58 > a. A single-assignment VM, which we've both already been thinking
62 however, by the prospect of a minimally allocated VM representation... I
78 VM). This is the point that disallows java style bytecodes, where all
87 > b. A strongly-typed VM. One question is do we need the types to be
[all …]
|
| D | 2000-11-18-EarlyDesignIdeas.txt | 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
28 a. A single-assignment VM, which we've both already been thinking about.
30 b. A strongly-typed VM. One question is do we need the types to be
33 c. How do we get more high-level information into the VM while keeping
34 to a low-level VM design?
|
| 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
14 advantages to have a much lower level VM layer, and do significant static
|
| /external/swiftshader/third_party/LLVM/include/llvm/Transforms/Utils/ |
| D | ValueMapper.h | 56 Value *MapValue(const Value *V, ValueToValueMapTy &VM,
60 void RemapInstruction(Instruction *I, ValueToValueMapTy &VM,
66 inline MDNode *MapValue(const MDNode *V, ValueToValueMapTy &VM,
69 return cast<MDNode>(MapValue((const Value*)V, VM, Flags, TypeMapper));
71 inline Constant *MapValue(const Constant *V, ValueToValueMapTy &VM,
74 return cast<Constant>(MapValue((const Value*)V, VM, Flags, TypeMapper));
|
| /external/llvm/lib/Transforms/Utils/ |
| D | ValueMapper.cpp | 88 ValueToValueMapTy *VM; member
92 explicit MappingContext(ValueToValueMapTy &VM, in MappingContext()
94 : VM(&VM), Materializer(Materializer) {} in MappingContext()
114 Mapper(ValueToValueMapTy &VM, RemapFlags Flags, in Mapper() argument
117 MCs(1, MappingContext(VM, Materializer)) {} in Mapper()
125 registerAlternateMappingContext(ValueToValueMapTy &VM, in registerAlternateMappingContext() argument
127 MCs.push_back(MappingContext(VM, Materializer)); in registerAlternateMappingContext()
165 void remapFunction(Function &F, ValueToValueMapTy &VM);
167 ValueToValueMapTy &getVM() { return *MCs[CurrentMCID].VM; } in getVM()
767 ValueToValueMapTy &VM; member
[all …]
|
| /external/autotest/client/site_tests/crosvm_Sanity/ |
| D | control | 15 TEST_CLASS = "VM"
19 Set baseline expectations for hosting Chrome OS VM images. In the Chrome OS lab
23 the only host environment, and it runs in a VM as well. We attempt to control
|
| /external/llvm/lib/Target/NVPTX/ |
| D | NVPTXGenericToNVVM.cpp | 58 void remapNamedMDNode(ValueToValueMapTy &VM, NamedMDNode *N);
129 ValueToValueMapTy VM; in runOnModule() local
131 VM[I->first] = I->second; in runOnModule()
136 remapNamedMDNode(VM, &I); in runOnModule()
364 void GenericToNVVM::remapNamedMDNode(ValueToValueMapTy &VM, NamedMDNode *N) { in remapNamedMDNode() argument
374 MDNode *NewOperand = MapMetadata(Operand, VM); in remapNamedMDNode()
|
| /external/autotest/server/site_tests/factory_InstallVM/ |
| D | control | 8 NAME = "Factory Install VM"
15 This test creates and runs a mini-Omaha server, boots a VM from the
|
| /external/llvm/lib/Target/AMDGPU/ |
| D | SIInsertWaits.cpp | 38 unsigned VM; member
188 Result.Named.VM = !!(TSFlags & SIInstrFlags::VM_CNT); in getHwCounts()
318 if (LastOpcodeType == VMEM && Increment.Named.VM) { in pushInstruction()
327 else if (Increment.Named.VM) in pushInstruction()
413 .addImm((Counts.Named.VM & 0xF) | in insertWait()
443 Counts.Named.VM = Imm & 0xF; in handleExistingWait()
|
| /external/autotest/client/site_tests/logging_AsanCrash/ |
| D | control | 9 # Normally all suite:smoke tests running in the VM should also run on hardware
10 # in bvt-inline. This test is an exception, as ASAN is VM specific.
|
| /external/python/cpython2/Lib/email/test/data/ |
| D | msg_06.txt | 13 X-Mailer: VM 6.95 under 21.4 (patch 4) "Artificial Intelligence" XEmacs Lucid
28 X-Mailer: VM 6.95 under 21.4 (patch 4) "Artificial Intelligence" XEmacs Lucid
|
| /external/python/cpython3/Lib/test/test_email/data/ |
| D | msg_06.txt | 13 X-Mailer: VM 6.95 under 21.4 (patch 4) "Artificial Intelligence" XEmacs Lucid
28 X-Mailer: VM 6.95 under 21.4 (patch 4) "Artificial Intelligence" XEmacs Lucid
|
| /external/valgrind/docs/internals/ |
| D | qemu-aarch64-linux-HOWTO.txt | 59 This gives you a root shell in the new VM. In that shell:
76 Now back in the VM, we can finish the installation.
94 Now you can ssh into the VM and install stuff as usual:
|
| /external/clang/test/CodeGenOpenCL/ |
| D | shifts.cl | 50 //OPT: [[VM:%.+]] = and <4 x i32> %b, <i32 31, i32 31, i32 31, i32 31>
51 //OPT-NEXT: [[VC:%.+]] = shl <4 x i32> %a, [[VM]]
|