| AsmJS.cpp |
/
// The asm.js valid heap lengths are precisely the WASM valid heap lengths for
// ARM greater or equal to MinHeapLength
static const size_t MinHeapLength = PageSize;
static uint32_t RoundUpToNextValidAsmJSHeapLength(uint32_t length) {
if (length <= MinHeapLength) {
return MinHeapLength;
}
return wasm::RoundUpToNextValidARMImmediate(length);
}
/**************************************************************************** |
208450 |
| AsmJS.h |
|
3374 |
| cranelift |
|
6 |
| Makefile |
|
2013 |
| moz.build |
|
1314 |
| WasmAST.h |
|
43897 |
| WasmBaselineCompile.cpp |
[SMDOC] WebAssembly baseline compiler (RabaldrMonkey)
General assumptions for 32-bit vs 64-bit code:
- A 32-bit register can be extended in-place to a 64-bit register on 64-bit
systems.
- Code that knows that Register64 has a '.reg' member on 64-bit systems and
'.high' and '.low' members on 32-bit systems, or knows the implications
thereof, is #ifdef JS_PUNBOX64. All other code is #if(n)?def JS_64BIT.
Coding standards:
- In "small" code generating functions (eg emitMultiplyF64, emitQuotientI32,
and surrounding functions; most functions fall into this class) where the
meaning is obvious:
- if there is a single source + destination register, it is called 'r'
- if there is one source and a different destination, they are called 'rs'
and 'rd'
- if there is one source + destination register and another source register
they are called 'r' and 'rs'
- if there are two source registers and a destination register they are
called 'rs0', 'rs1', and 'rd'.
- Generic temp registers are named /temp[0-9]?/ not /tmp[0-9]?/.
- Registers can be named non-generically for their function ('rp' for the
'pointer' register and 'rv' for the 'value' register are typical) and those
names may or may not have an 'r' prefix.
- "Larger" code generating functions make their own rules.
General status notes:
"FIXME" indicates a known or suspected bug. Always has a bug#.
"TODO" indicates an opportunity for a general improvement, with an additional
tag to indicate the area of improvement. Usually has a bug#.
There are lots of machine dependencies here but they are pretty well isolated
to a segment of the compiler. Many dependencies will eventually be factored
into the MacroAssembler layer and shared with other code generators.
High-value compiler performance improvements:
- (Bug 1316802) The specific-register allocator (the needI32(r), needI64(r)
etc methods) can avoid syncing the value stack if the specific register is
in use but there is a free register to shuffle the specific register into.
(This will also improve the generated code.) The sync happens often enough
here to show up in profiles, because it is triggered by integer multiply
and divide.
High-value code generation improvements:
- (Bug 1316804) brTable pessimizes by always dispatching to code that pops
the stack and then jumps to the code for the target case. If no cleanup is
needed we could just branch conditionally to the target; if the same amount
of cleanup is needed for all cases then the cleanup can be done before the
dispatch. Both are highly likely.
- (Bug 1316806) Register management around calls: At the moment we sync the
value stack unconditionally (this is simple) but there are probably many
common cases where we could instead save/restore live caller-saves
registers and perform parallel assignment into argument registers. This
may be important if we keep some locals in registers.
- (Bug 1316808) Allocate some locals to registers on machines where there are
enough registers. This is probably hard to do well in a one-pass compiler
but it might be that just keeping register arguments and the first few
locals in registers is a viable strategy; another (more general) strategy
is caching locals in registers in straight-line code. Such caching could
also track constant values in registers, if that is deemed valuable. A
combination of techniques may be desirable: parameters and the first few
locals could be cached on entry to the function but not statically assigned
to registers throughout.
(On a large corpus of code it should be possible to compute, for every
signature comprising the types of parameters and locals, and using a static
weight for loops, a list in priority order of which parameters and locals
that should be assigned to registers. Or something like that. Wasm makes
this simple. Static assignments are desirable because they are not flushed
to memory by the pre-block sync() call.)
|
380569 |
| WasmBaselineCompile.h |
|
2694 |
| WasmBuiltins.cpp |
|
53612 |
| WasmBuiltins.h |
|
4697 |
| WasmCode.cpp |
static |
45199 |
| WasmCode.h |
|
24668 |
| WasmCompile.cpp |
|
25073 |
| WasmCompile.h |
|
5427 |
| WasmConstants.h |
|
14163 |
| WasmCraneliftCompile.cpp |
|
17970 |
| WasmCraneliftCompile.h |
|
1328 |
| WasmDebug.cpp |
|
15114 |
| WasmDebug.h |
|
5517 |
| WasmFrameIter.cpp |
|
53463 |
| WasmFrameIter.h |
|
9241 |
| WasmGC.cpp |
|
4369 |
| WasmGC.h |
|
13181 |
| WasmGenerator.cpp |
limitedSize= |
39837 |
| WasmGenerator.h |
|
7793 |
| WasmInstance.cpp |
|
67994 |
| WasmInstance.h |
|
11039 |
| WasmIonCompile.cpp |
prev |
130031 |
| WasmIonCompile.h |
|
1389 |
| WasmJS.cpp |
|
116281 |
| WasmJS.h |
|
15481 |
| WasmModule.cpp |
|
43565 |
| WasmModule.h |
|
9675 |
| WasmOpIter.cpp |
|
12722 |
| WasmOpIter.h |
|
80860 |
| WasmProcess.cpp |
|
12435 |
| WasmProcess.h |
|
2136 |
| WasmRealm.cpp |
|
4584 |
| WasmRealm.h |
|
2709 |
| WasmSerialize.h |
|
5780 |
| WasmSignalHandlers.cpp |
|
40319 |
| WasmSignalHandlers.h |
|
2877 |
| WasmStubs.cpp |
|
86163 |
| WasmStubs.h |
|
10942 |
| WasmTable.cpp |
static |
11789 |
| WasmTable.h |
|
4347 |
| WasmTextToBinary.cpp |
|
214738 |
| WasmTextToBinary.h |
|
1407 |
| WasmTypes.cpp |
|
28273 |
| WasmTypes.h |
|
81217 |
| WasmUtility.h |
|
725 |
| WasmValidate.cpp |
|
89538 |
| WasmValidate.h |
|
29760 |