Intel recommends against the use of -Os, and using it seems to produce
incorrect code in many recent versions of Intel's compilers.
js/src/Makefile.in tries to use -Os only with G++, but it tests
INTEL_CC, not INTEL_CXX --- even though almost all the sources are
C++. Check INTEL_CXX instead.
Here's the commit that added this:
1.1764 <benjamin@smedbergs.us> 2007-01-31 08:12
No bug: checking to see which tinderboxes don't have python available.
It seems unlikely that this echo was meant to stay in the configure script.
LirBuffer has been modified to provide advance warning of
out of memory (OOM) conditions.
A new page is allocated LIR_BUF_THRESHOLD instructions
prior to reaching the end of page. If the page allocation fails,
call to outOmem() will return true. The buffer can still be
safely written to during during this period but it is assumed
the higher level code will catch this condition and handle
it appropriately as writing LIR_BUF_THRESHOLD instructions
past this point will cause a crash.
This opportunity was also taken to re-factor the code for
LirBufWriter making it more platform agnostic.
- All non-LInsp data in the instruction stream is now managed
through structures that overlay the memory region.
- prepFor() was added to replace the multiple
ensureReferenceable() calls for each instruction.
- insCall() was also modified somewhat in that the
arguments are now stored growing downwards from
the position of the pseudo instruction LirCallIns.
CodegenLIR now has LirBuffer checks at the granularity
of each emitXXX() call that is exposed publicly. This seemed
like a reasonable approach since a client could potentially
call at this level indefinitely. If we want to reduce the frequency
of these checks then we'd have to push the check up into the
verifier.
Assembler OOM handling has also changed. The variable
_startingIns was added and contains the location at which
the assembler began writing code for the current
begin/assem/end sequence. If an OOM condition occurs
the assembler will reset the current instruction pointer
to _startingIns, effectively overwriting the code that has
been generated. This allows the assembler to produce
code indefinitely (and without error) until the upper layers
have noticed the error and respond accordingly.
The constant LARGEST_UNDERRUN_PROT was added
and needs to be set to a platform specific value that is
equal to or greater than the number of NIns written for
the largest possible instruction. i.e. you cannot write
more than this number of NIns to the buffer for each
call to underrunProtect().
