I'm pushing this on behalf of nnethercote since tamarin had one additional
regression failure that this patch fixes. Comments from the bug:
Bug 520712 introduced some underrunProtect() problems in the X64 backend. A
follow-up patch fixed one of them, but there are several remaining. This patch
fixes all of them, AFAICT, and commons out some code in the process hopefully
making things less error-prone. (It also fixes a printf-style compile
warning.)
I tested this by reducing the size of chunks allocated by codeAlloc to only 128
bytes. After doing that, without this patch, Tracemonkey was fairly crashy and
Tamarin was totally crashy; with the patch both were fine, albeit slower than
usual. (I tried 64 bytes as well but got assertions in the code allocator,
that seems to be Just Too Small.)
--HG--
extra : convert_revision : 7972be6204883c0ba472fe8caaa08f0b08660e72
2009-11-19: checkReportFlags adjusted to use js_GetTopStackFrame, to
satisfy static analysis checks. No effect on Sunspider.
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.
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
