Lines Matching refs:assembler

2  * Avoid any new API at the assembler level
4  * Keep the literal pool at the macro-assembler level
6  * The macro-assembler will have its own literal pool, and will manage
8  * The macro-assembler is responsible for emitting its managed literal
10  * The assembler does not manage literals, but can place a literal in the
19 So, the macro-assembler will have to wait for the instruction to be emitted
20 at the assembler level, as the assembler may choose the variant to emit, to
33 The macro assembler then manages the checkpoint which defines when the
34 macro-assembler’s internal pool has to be emitted.
49     via the macro-assembler because the assembler has no knowledge of the literal
53  3. The assembler emits an unconditional branch, a return from function or
61 not be managed by the macro-assembler, and it’s the responsibility of the
65 literal pool will be fully managed by the macro-assembler, and
66 automatically emitted when the macro-assembler detects that it can/should.
72 the code at the assembler level, then used as labels for ldr* and all
80 macro-assembler, the literal may be associated to a literal pool, and the
81 assembler places the literal. If the literal is linked to literal pool, the
82 assembler will have callbacks in the macro-assembler (as sub class of the
83 assembler)... So, it’s pretty hard to manage all this. Here's a gdb trace:
99 …vixl::aarch64::RawLiteral::SetLastUse (this, offset=40) at src/vixl/aarch64/assembler-aarch64.h:11…
111 …64::LiteralPool::NextRecommendedCheckpoint (this) at src/vixl/aarch64/macro-assembler-aarch64.h:155
114 …tNextRecommendedCheckpoint (this, offset=131112) at src/vixl/aarch64/macro-assembler-aarch64.h:3130
117 …ote that we've modified a *private* member of the MacroAssembler through a call to the assembler **