At compile-time, we must consult the current JSTreeContext to decide
whether to issue an strict mode error; at run-time, we need to
check the strictness of the currently executing script. Both cases
also check the context options. The design is supposed to make it
easy to follow the principle that conditions treated as errors in
strict mode are a subset of those warned about by JSOPTION_STRICT.
This patch removes report flag handling from js_ExpandErrorArguments,
which is used for both compile-time and run-time errors. At run-time,
the new checkReportFlags handles the checks. At compile-time, we need
different checks depending on the situation, so the checks are done in
js_ReportStrictModeError, js_ReportCompileErrorNumber, and the new
ReportCompileErrorNumberVA.
These macros were intended to help avoid passing unused parameters
when JS_ARENAMETER is not defined, but they're not worth the trouble.
The unused parameter doesn't elicit warnings, and the performance
impact of passing the unneeded argument is negligible.
This also removes support for JS_ARENA_CONST_ALIGN_MASK, which is not
used.
When we test the size of an offset, we have to do it after underrunProtect
or else a jump can be inserted which then invalidates the instruction selection.
--HG--
extra : convert_revision : 9b249328236ffec433abb961c0737a82f437c7d4
new opcode: LIR_jtbl. jtbl takes a uint32_t index and a table of label
references (LIns**), representing a jump to one of the labels.
the index must be in range (range checking is not included in the opcode).
the table is allocated in memory at least as long lived as the LIR; this is
accomplished by doing the allocation from the same Allocator used by LirBuffer.
In the x86 backend, this is implemented with a simple jmp [R*4+ADDR] where ADDR
is the address of the table. I added a new dataAllocator (Allocator&)
parameter to Assembler, which is used for allocating data along with code (data
& code have same lifetime). The x86 backend allocates the final table of
addresses from this allocator and embeds the pointer to the table in code.
In other backends more than one instruction must be used due to limited range
of the constant part of the addressing mode (ppc, arm), or non-support for
full-range pc-relative indexing (x64, ppc64).
Anyone generating LIR code for use with LIR_jtbl must also generate a
LIR_regfence instruction after each label reachable by a forwards edge
from LIR_jtbl. This is to workaround the register allocator's inability
to merge register states between 2 or more pre-existing targets. LIR_regfence
is not required for backwards edges.
--HG--
extra : convert_revision : ee709eaaa30f720f77ab863ba4c9e6d10d69982b
