Lines Matching refs:is
7 JIT/AOT compiler has a `SlowPath` mechanism. It is used for some opcodes where a call to runtime is…
9 During code generation so-called `SlowPath` code is created, and we put it into a special cold code…
10 Unique `SlowPath` blob is generated for each place it is called, and as it contains saving register…
11 `BoundaryFrame` for stack walker, it's code is much longer than few runtime-call-related instructio…
17 The problem is that such a `SlowPath` would be actually required only once when we first time reach…
18 …Id`. So, in order to reduce code size in AOT mode, more tricky solution with PLT Resolvers is used.
23 consecutive slots are reserved in PLT-GOT table. `FirstSlot` is filled during AOT file creation and…
24 `SecondSlot` is filled during AOT file loading into runtime and contains `PLT CallStatic Resolver` …
25 …ould actually store `Method pointer` after resolving, but during AOT file loading it is initialized
28 During calls, first parameter is always a callee `Method pointer`, so the trick from previous parag…
29 …r code generation. Lets see `arm64` example (`GetCompiledEntryPointOffset` is 56 = 7 * 8, all func…
60 When we have `Method pointer`, it is stored into `ThirdSlot`, allow to load proper executable addre…
61 parameter in actual method call. Jump by register value operation is used instead of call to return…
67 slots are reserved in PLT-GOT table. `FirstSlot` is filled during AOT file creation and contains `m…
68 `SecondSlot` is filled with zero and after resolving it stores `VTable index` incremented by 1.
90 XX+20: blr x30 ; Call Resolver, x16 is like a "parameter" and "return value"
93 …6, [x16, #160] ; Load Method from VTable (compensating index+1, as VTable start offset is 168)
103 Unlike CallStatic, there is no way to use default parameter registers to send/receive values into r…
104 Thus for `PLT CallVirtual Resolver` convention is the following - first `Encoder` temporary register
105 (`x16` for `arm64` or `r12` for `x86_84`) is a parameter with `SecondSlot` address and also the sam…
110 Having `Method pointer` it is easy to load `VTable index` value.
112 Control is returned back into code instead.
117 three consecutive slots are reserved in PLT-GOT table. `FirstSlot` is filled during AOT file creati…
119 When `SecondSlot` in non-zero it means that `Class` is known to be in `Initialized` state already.
151 For class-related resolvers convention is the following - first `Encoder` temporary register
152 (`x16` for `arm64` or `r12` for `x86_84`) is a parameter with Slot address, and it is also used as …
157 The condition is whether `Class` state is `Initialized`, as returning from `InitializeClassById` en…
158 cases can happen when `Class` is yet only in `Initializing` state.
161 Another entrypoint is called here - `ResolveClass`. Gathered `Class pointer` value is stored into `…
168 Moreover, it is placed in platform-independent file `code_generator/target/target.cpp`, although th…
171 Main difference between two supported platforms is a main temporary register to use in Resolver.
172 For `arm64` we use `LR` register (`x30`), and for `x86_64` third `Encoder` temporary - `r14` is use…
174 One more issue is that first `Encoder` temporary register (`x16` for `arm64` or `r12` for `x86_84`)…
175 in 3 Resolvers (all but CallStatic) is actually a caller-saved for `arm64`, but callee-saved for `x…
180 On `arm64` is is just a one `stp x29, x30, [sp, #-16]` instruction,while on `x86` caller return add…
191 Stack pointer is temporarily manually adjusted in this case to allow `SaveCallerRegisters` function…
195 This step is described above separately in each resolver description.
202 This step is done using `MakeCallAot` function with properly calculated offset. Resolvers are place…
213 On `x86_64` this step is not required, as `r12` appears to be callee-saved register and is restored…
214 Main logic of this step is described above separately in each resolver description.
218 while in other Resolvers it is temporarily manually adjusted to previous frame before calling `Load…