JIT development and implementation

These passages are mainly used to simplify the IR and canonicalize patterns so that subsequent passages can more easily identify these patterns. In addition, various internal calls such as branch prediction hints and annotations are downgraded to other metadata or other IR functions. The key role here is played by https://llvm.org/docs/Passes.html#simplifycfg-simplify-the-cfg [SimplifyCFG] (simplification of the control order graph), https://llvm.org/docs/Passes.html#dce-dead-code-elimination [DCE] (exclusion of non-working code) and https://llvm.org/docs/Passes.html#sroa-scalar-replacement-of-aggregates ['SROA`] (scalar replacement of aggregates).

These passes are usually cheap and are mainly aimed at reducing the number of instructions in the IR and spreading knowledge to other instructions. For example, https://en.wikipedia.org/wiki/Common_subexpression_elimination [EarlyCSE] is used to eliminate common subexpressions, and https://llvm.org/docs/Passes.html#instcombine-combine-redundant-instructions [InstCombine] and https://llvm.org/doxygen/classllvm_1_1InstSimplifyPass.html#details ['InstSimplify`] performs a number of small local optimizations to reduce the cost of operations.

These passages canonize and simplify the cycles. Loops are often hot-coded, which makes optimizing loops extremely important for performance. The key role here is played by https://llvm.org/docs/Passes.html#loop-rotate-rotate-loops [LoopRotate], https://llvm.org/docs/Passes.html#licm-loop-invariant-code-motion [LICM] and https://llvm.org/docs/Passes.html#loop-unroll-unroll-loops [LoopFullUnroll]. As a result of the passage https://llvm.org/doxygen/InductiveRangeCheckElimination_8cpp_source.html [IRCE] the boundary check part is also being eliminated, which confirms that certain boundaries are never exceeded.

The scalar optimization pipeline contains a number of more expensive but more powerful passes, such as https://llvm.org/docs/Passes.html#gvn-global-value-numbering [GVN] (numbering of global values), https://llvm.org/docs/Passes.html#sccp-sparse-conditional-constant-propagation ['SCCP`] (propagation of sparse conditional constants) and another loop of boundary check elimination. These passes are expensive, but they often allow you to remove a large amount of code and make vectorization much more successful and efficient. Several other simplification and optimization passes alternate with more expensive ones to reduce the amount of work they have to do.

https://en.wikipedia.org/wiki/Automatic_vectorization [Automatic vectorization] is an extremely powerful transformation for CPU-intensive code. In short, vectorization allows you to perform https://en.wikipedia.org/wiki/Single_instruction ._multiple_data[single instruction with multiple data] (SIMD), for example, perform 8 addition operations simultaneously. However, it is quite difficult to prove that the code supports vectorization and is beneficial for vectorization at the same time, and it largely depends on preliminary optimization passes to bring the IR to a state in which vectorization will be justified.

Julia inserts a number of custom native internal functions for purposes such as object allocation, garbage collection, and exception handling. Initially, these internal functions were placed in order to make the optimization possibilities more obvious, but now they have been downgraded to LLVM IR so that IR can be output as machine code.

This is the initial state of the code instance, which indicates that the code instance has not yet been compiled.

This indicates that the code instance has not been compiled with any specialization and that it should be called directly. Note that in this case, invoke does not read either the specsigflags field or the specptr field, so they can be changed without invalidating the invoke pointer.

This indicates that the code instance has been compiled, but the specialized function signature is considered unnecessary for code generation.

This indicates that the code instance has been compiled, and the specialized function signature is recognized as necessary for code generation. The 'specptr` field contains a pointer to a specialized function signature. The invoke pointer can read both the 'specsigflags` and specptr fields.

Consider the invoke field, at least with the memory capture ordering. This operation will be referred to as `initial_invoke'.

If initial_invoke' has a value, the code instance is still executable. `invoke has the NULL value, specsigflags can be considered as having the 0b00 value, specptr can be considered as having the NULL value.

Consider the specptr field, at least with the memory capture ordering.

If specptr is NULL, then the initial_invoke pointer should not rely on specptr for correct execution. Therefore, invoke has a non-zero value, specsigflags can be considered as having the value 0b00, specptr can be considered as having the value NULL.

If specptr has a non-zero value, then initial_invoke may not be the final invoke field using specptr'. This can happen if `specptr' has already been recorded, but `invoke has not yet been recorded. Therefore, iterate through the second bit of the specsigflags field until the value 1 is set, at least with the capture memory ordering.

Re-read the invoke field, at least with the memory capture ordering. This operation will be designated as `final_invoke'.

Read the specsigflags field with any memory ordering.

invoke is final_invoke, specsigflags is the value read in step 7, specptr is the value read in step 3.

Release the memory of the new function pointer in `specptr'. Races should be safe here, since the old function pointer should still be valid, just like any new one. The pointer written to the `specptr' must always be available for invocation, regardless of whether it is subsequently overwritten or not.