Name Description Size
AliasAnalysis.cpp 16444
AliasAnalysis.h jit_AliasAnalysis_h 1605
AlignmentMaskAnalysis.cpp 3204
AlignmentMaskAnalysis.h namespace jit 726
AtomicOp.h jit_AtomicOp_h 2983
AtomicOperations.h [SMDOC] Atomic Operations The atomic operations layer defines types and functions for JIT-compatible atomic operation. The fundamental constraints on the functions are: - That their realization here MUST be compatible with code the JIT generates for its Atomics operations, so that an atomic access from the interpreter or runtime - from any C++ code - really is atomic relative to a concurrent, compatible atomic access from jitted code. That is, these primitives expose JIT-compatible atomicity functionality to C++. - That accesses may race without creating C++ undefined behavior: atomic accesses (marked "SeqCst") may race with non-atomic accesses (marked "SafeWhenRacy"); overlapping but non-matching, and hence incompatible, atomic accesses may race; and non-atomic accesses may race. The effects of races need not be predictable, so garbage can be produced by a read or written by a write, but the effects must be benign: the program must continue to run, and only the memory in the union of addresses named in the racing accesses may be affected. The compatibility constraint means that if the JIT makes dynamic decisions about how to implement atomic operations then corresponding dynamic decisions MUST be made in the implementations of the functions below. The safe-for-races constraint means that by and large, it is hard to implement these primitives in C++. See "Implementation notes" below. The "SeqCst" suffix on operations means "sequentially consistent" and means such a function's operation must have "sequentially consistent" memory ordering. See mfbt/Atomics.h for an explanation of this memory ordering. Note that a "SafeWhenRacy" access does not provide the atomicity of a "relaxed atomic" access: it can read or write garbage if there's a race. Implementation notes. It's not a requirement that these functions be inlined; performance is not a great concern. On some platforms these functions may call out to code that's generated at run time. In principle these functions will not be written in C++, thus making races defined behavior if all racy accesses from C++ go via these functions. (Jitted code will always be safe for races and provides the same guarantees as these functions.) The appropriate implementations will be platform-specific and there are some obvious implementation strategies to choose from, sometimes a combination is appropriate: - generating the code at run-time with the JIT; - hand-written assembler (maybe inline); or - using special compiler intrinsics or directives. Trusting the compiler not to generate code that blows up on a race definitely won't work in the presence of TSan, or even of optimizing compilers in seemingly-"innocuous" conditions. (See https://www.usenix.org/legacy/event/hotpar11/tech/final_files/Boehm.pdf for details.) 15051
BacktrackingAllocator.cpp 109961
BacktrackingAllocator.h 27719
Bailouts.cpp excInfo = 11810
Bailouts.h 9198
BaselineBailouts.cpp BaselineStackBuilder helps abstract the process of rebuilding the C stack on the heap. It takes a bailout iterator and keeps track of the point on the C stack from which the reconstructed frames will be written. It exposes methods to write data into the heap memory storing the reconstructed stack. It also exposes method to easily calculate addresses. This includes both the virtual address that a particular value will be at when it's eventually copied onto the stack, as well as the current actual address of that value (whether on the heap allocated portion being constructed or the existing stack). The abstraction handles transparent re-allocation of the heap memory when it needs to be enlarged to accommodate new data. Similarly to the C stack, the data that's written to the reconstructed stack grows from high to low in memory. The lowest region of the allocated memory contains a BaselineBailoutInfo structure that points to the start and end of the written data. 75553
BaselineCacheIRCompiler.cpp 112314
BaselineCacheIRCompiler.h jit_BaselineCacheIRCompiler_h 4554
BaselineCodeGen.cpp HandlerArgs = 203811
BaselineCodeGen.h 18515
BaselineDebugModeOSR.cpp 19256
BaselineDebugModeOSR.h 1026
BaselineFrame-inl.h jit_BaselineFrame_inl_h 3184
BaselineFrame.cpp 5750
BaselineFrame.h 15699
BaselineFrameInfo-inl.h jit_BaselineFrameInfo_inl_h 1155
BaselineFrameInfo.cpp 6675
BaselineFrameInfo.h 13114
BaselineIC.cpp 126226
BaselineIC.h 65436
BaselineICList.h jit_BaselineICList_h 4581
BaselineInspector.cpp 48235
BaselineInspector.h jit_BaselineInspector_h 4653
BaselineJIT.cpp 34081
BaselineJIT.h 21574
BitSet.cpp 2573
BitSet.h jit_BitSet_h 4187
BytecodeAnalysis.cpp stackDepth= 8746
BytecodeAnalysis.h jit_BytecodeAnalysis_h 2335
CacheIR.cpp 338215
CacheIR.h 69697
CacheIRCompiler.cpp 253139
CacheIRCompiler.h 43181
CacheIRHealth.cpp JS_CACHEIR_SPEW 3620
CacheIRHealth.h JS_CACHEIR_SPEW 2226
CacheIROps.yaml 40574
CacheIRSpewer.cpp 13735
CacheIRSpewer.h JS_CACHEIR_SPEW 3043
CodeGenerator.cpp 504365
CodeGenerator.h 15774
CompactBuffer.h 6430
CompileInfo-inl.h jit_CompileInfo_inl_h 2587
CompileInfo.h JavaScript execution, not analysis. 17206
CompileWrappers.cpp static 7578
CompileWrappers.h 3713
Disassemble.cpp 2974
Disassemble.h jit_Disassemble_h 649
EdgeCaseAnalysis.cpp 1431
EdgeCaseAnalysis.h jit_EdgeCaseAnalysis_h 710
EffectiveAddressAnalysis.cpp 6987
EffectiveAddressAnalysis.h namespace jit 884
ExecutableAllocator.cpp willDestroy = 10523
ExecutableAllocator.h 6386
FixedList.h jit_FixedList_h 2183
FlushICache.h Flush the instruction cache of instructions in an address range. 1131
FoldLinearArithConstants.cpp namespace jit 3592
FoldLinearArithConstants.h namespace jit 649
GenerateCacheIRFiles.py \ /* This Source Code Form is subject to the terms of the Mozilla Public * License, v. 2.0. If a copy of the MPL was not distributed with this * file, You can obtain one at http://mozilla.org/MPL/2.0/. */ #ifndef %(includeguard)s #define %(includeguard)s /* This file is generated by jit/GenerateCacheIRFiles.py. Do not edit! */ %(contents)s #endif // %(includeguard)s 19125
GenerateOpcodeFiles.py \ /* This Source Code Form is subject to the terms of the Mozilla Public * License, v. 2.0. If a copy of the MPL was not distributed with this * file, You can obtain one at http://mozilla.org/MPL/2.0/. */ #ifndef %(includeguard)s #define %(includeguard)s /* This file is generated by jit/GenerateOpcodeFiles.py. Do not edit! */ #define %(listname)s(_) \\ %(ops)s #endif // %(includeguard)s 2033
ICState.h jit_ICState_h 4828
ICStubSpace.h jit_ICStubSpace_h 1998
InlinableNatives.cpp 11393
InlinableNatives.h 10186
InlineList.h 15550
InstructionReordering.cpp 7248
InstructionReordering.h 592
Ion.cpp 87805
Ion.h this 4980
IonAnalysis.cpp 169881
IonAnalysis.h 6466
IonBuilder.cpp 409672
IonBuilder.h 53115
IonCacheIRCompiler.cpp 83348
IonCacheIRCompiler.h jit_IonCacheIRCompiler_h 2714
IonCompileTask.cpp 7610
IonCompileTask.h jit_IonCompileTask_h 2830
IonIC.cpp static 23847
IonIC.h 19458
IonInstrumentation.h jit_IonInstrumentatjit_h 854
IonOptimizationLevels.cpp 6432
IonOptimizationLevels.h 9607
IonScript.h 19705
IonTypes.h 32098
JSJitFrameIter-inl.h jit_JSJitFrameIter_inl_h 1992
JSJitFrameIter.cpp 24161
JSJitFrameIter.h 27698
JSONSpewer.cpp 7138
JSONSpewer.h JS_JITSPEW 1192
Jit.cpp osrFrame = 6252
Jit.h jit_Jit_h 985
JitAllocPolicy.h 5581
JitCode.h 5899
JitCommon.h 2324
JitContext.cpp 4707
JitContext.h jit_JitContext_h 4372
JitFrames-inl.h jit_JitFrames_inl_h 1025
JitFrames.cpp 82391
JitFrames.h 28641
JitOptions.cpp 12773
JitOptions.h jit_JitOptions_h 4580
JitRealm.h 25407
JitScript-inl.h Note: for non-escaping arguments, argTypes reflect only the initial type of the variable (e.g. passed values for argTypes, or undefined for localTypes) and not types from subsequent assignments. 3873
JitScript.cpp static 27489
JitScript.h [SMDOC] ICScript Lifetimes An ICScript owns an array of ICEntries, each of which owns a linked list of ICStubs. A JitScript contains an embedded ICScript. If it has done any trial inlining, it also owns an InliningRoot. The InliningRoot owns all of the ICScripts that have been created for inlining into the corresponding JitScript. This ties the lifetime of the inlined ICScripts to the lifetime of the JitScript itself. We store pointers to ICScripts in two other places: on the stack in BaselineFrame, and in IC stubs for CallInlinedFunction. The ICScript pointer in a BaselineFrame either points to the ICScript embedded in the JitScript for that frame, or to an inlined ICScript owned by a caller. In each case, there must be a frame on the stack corresponding to the JitScript that owns the current ICScript, which will keep the ICScript alive. Each ICStub is owned by an ICScript and, indirectly, a JitScript. An ICStub that uses CallInlinedFunction contains an ICScript for use by the callee. The ICStub and the callee ICScript are always owned by the same JitScript, so the callee ICScript will not be freed while the ICStub is alive. The lifetime of an ICScript is independent of the lifetimes of the BaselineScript and IonScript/WarpScript to which it corresponds. They can be destroyed and recreated, and the ICScript will remain valid. 28420
JitSpewer.cpp 17972
JitSpewer.h Information during sinking 9692
JitcodeMap.cpp 44787
JitcodeMap.h The Ion jitcode map implements tables to allow mapping from addresses in ion jitcode to the list of (JSScript*, jsbytecode*) pairs that are implicitly active in the frame at that point in the native code. To represent this information efficiently, a multi-level table is used. At the top level, a global splay-tree of JitcodeGlobalEntry describings the mapping for each individual IonCode script generated by compiles. The entries are ordered by their nativeStartAddr. Every entry in the table is of fixed size, but there are different entry types, distinguished by the kind field. 38479
LICM.cpp 8967
LICM.h jit_LICM_h 661
LIR.cpp 19277
LIR.h 64221
Label.h 3513
Linker.cpp 2386
Linker.h jit_Linker_h 1171
Lowering.cpp useAtStart = 183968
Lowering.h useAtStart = 2403
MCallOptimize.cpp 131588
MIR.cpp 194570
MIR.h Everything needed to build actual MIR instructions: the actual opcodes and instructions, the instruction interface, and use chains. 425034
MIRBuilderShared.h 8513
MIRGenerator.h 5258
MIRGraph.cpp 46522
MIRGraph.h 33276
MacroAssembler-inl.h 34161
MacroAssembler.cpp 148820
MacroAssembler.h 177998
MoveEmitter.h jit_MoveEmitter_h 932
MoveResolver.cpp 14064
MoveResolver.h 9749
PcScriptCache.h jit_PcScriptCache_h 2432
PerfSpewer.cpp 9048
PerfSpewer.h jit_PerfSpewer_h 2892
ProcessExecutableMemory.cpp Inspiration is V8's OS::Allocate in platform-win32.cc. VirtualAlloc takes 64K chunks out of the virtual address space, so we keep 16b alignment. x86: V8 comments say that keeping addresses in the [64MiB, 1GiB) range tries to avoid system default DLL mapping space. In the end, we get 13 bits of randomness in our selection. x64: [2GiB, 4TiB), with 25 bits of randomness. 25362
ProcessExecutableMemory.h 4437
RangeAnalysis.cpp 116022
RangeAnalysis.h 25423
Recover.cpp 46288
Recover.h 22016
RegisterAllocator.cpp 19849
RegisterAllocator.h 11543
RegisterSets.h 39240
Registers.h 10004
RematerializedFrame-inl.h 746
RematerializedFrame.cpp static 6510
RematerializedFrame.h 7369
Safepoints.cpp 16048
Safepoints.h jit_Safepoints_h 3724
ScalarReplacement.cpp 43345
ScalarReplacement.h jit_ScalarReplacement_h 707
SharedICHelpers-inl.h jit_SharedICHelpers_inl_h 1064
SharedICHelpers.h jit_SharedICHelpers_h 1028
SharedICRegisters.h jit_SharedICRegisters_h 1090
Simulator.h jit_Simulator_h 778
Sink.cpp 9392
Sink.h jit_Sink_h 630
Snapshots.cpp 21669
Snapshots.h 16194
StackSlotAllocator.h jit_StackSlotAllocator_h 3481
TIOracle.cpp 1551
TIOracle.h jit_TIOracle_h 3305
TemplateObject-inl.h jit_TemplateObject_inl_h 4192
TemplateObject.h jit_TemplateObject_h 3424
TrialInlining.cpp 11053
TrialInlining.h [SMDOC] Trial Inlining WarpBuilder relies on transpiling CacheIR. When inlining scripted functions in WarpBuilder, we want our ICs to be as monomorphic as possible. Functions with multiple callers complicate this. An IC in such a function might be monomorphic for any given caller, but polymorphic overall. This make the input to WarpBuilder less precise. To solve this problem, we do trial inlining. During baseline execution, we identify call sites for which it would be useful to have more precise inlining data. For each such call site, we allocate a fresh ICScript and replace the existing call IC with a new specialized IC that invokes the callee using the new ICScript. Other callers of the callee will continue using the default ICScript. When we eventually Warp-compile the script, we can generate code for the callee using the IC information in our private ICScript, which is specialized for its caller. The same approach can be used to inline recursively. 3715
TypePolicy.cpp 49569
TypePolicy.h 18843
VMFunctionList-inl.h 24880
VMFunctions.cpp extraValuesToPop = 67823
VMFunctions.h 40395
ValueNumbering.cpp [SMDOC] IonMonkey Value Numbering Some notes on the main algorithm here: - The SSA identifier id() is the value number. We do replaceAllUsesWith as we go, so there's always at most one visible value with a given number. - Consequently, the GVN algorithm is effectively pessimistic. This means it is not as powerful as an optimistic GVN would be, but it is simpler and faster. - We iterate in RPO, so that when visiting a block, we've already optimized and hashed all values in dominating blocks. With occasional exceptions, this allows us to do everything in a single pass. - When we do use multiple passes, we just re-run the algorithm on the whole graph instead of doing sparse propagation. This is a tradeoff to keep the algorithm simpler and lighter on inputs that don't have a lot of interesting unreachable blocks or degenerate loop induction variables, at the expense of being slower on inputs that do. The loop for this always terminates, because it only iterates when code is or will be removed, so eventually it must stop iterating. - Values are not immediately removed from the hash set when they go out of scope. Instead, we check for dominance after a lookup. If the dominance check fails, the value is removed. 46601
ValueNumbering.h jit_ValueNumbering_h 4440
WarpBuilder.cpp maybePred = 99653
WarpBuilder.h Intentionally not implemented 8933
WarpBuilderShared.cpp 3444
WarpBuilderShared.h 1470
WarpCacheIRTranspiler.cpp 79630
WarpCacheIRTranspiler.h jit_WarpCacheIRTranspiler_h 1440
WarpOracle.cpp 36755
WarpOracle.h jit_WarpOracle_h 2231
WarpSnapshot.cpp 10010
WarpSnapshot.h 18804
WasmBCE.cpp 4518
WasmBCE.h jit_wasmbce_h 964
arm 25
arm64 20
mips-shared 19
mips32 20
mips64 20
moz.build 8549
none 10
shared 18
x64 16
x86 16
x86-shared 21