Lines Matching refs:Cfg
12 The result is a queue of Cfg pointers. The parser thread incrementally adds a
13 Cfg pointer to the queue after the Cfg is created, and then moves on to parse
16 Multiple translation worker threads draw from the queue of Cfg pointers as they
26 translation thread (including Cfg nodes, instructions, and most kinds of
63 Several object types are scoped within the lifetime of the Cfg. These include
65 When the Cfg is destroyed, these scoped objects are destroyed as well. To keep
66 this cheap, the Cfg includes a slab allocator from which these objects are
70 providing the container with an allocator that uses the Cfg-local slab
73 straightforward since on any of the threads, only one Cfg is active at a time,
74 and a given Cfg is only active in one thread at a time (either the parser
79 thread wants to destroy the Cfg and reclaim all its memory after translation
83 Cfg and its allocator are transferred to the translation thread after parsing
89 Part of the Cfg building, and transformations on the Cfg, include STL container
93 When the parser thread creates a new Cfg object, it puts a pointer to the Cfg's
94 slab allocator into its own TLS. This is used as the Cfg is built within the
95 parser thread. After the Cfg is built, the parser thread clears its allocator
96 pointer, adds the new Cfg pointer to the translation queue, continues with the
99 When the translation thread grabs a new Cfg pointer, it installs the Cfg's slab
101 assembly buffer, it must take care not to use the Cfg's slab allocator. If
105 The translation thread destroys the Cfg when it is done translating, including
106 the Cfg's slab allocator, and clears the allocator pointer from its TLS.