The implemetation of Assembler::actualOffset() is now a no-op in all
targets, and it is no longer necessary to rewrite assembler buffer
offsets to their final form after finishing the assembler buffer.
- Delete Assembler::actualOffset() in all targets.
- Delete AsmJSModule::CodeRange::updateOffsets().
- Delete AsmJSModule::updateCodeOffset().
- Delete AsmJSModule::updateOffsets().
- Delete CodeOffsetLabel::fixup().
- Delete ICEnty::fixupReturnOffset().
- Delete LSafepoint::fixupOffset().
- Delete OsiIndex::fixUpOffset().
- Delete PCMappingEntry::fixupNativeOffset().
Also delete all code calling these functions.
The ARM assembler no longer needs to keep track of code offsets for
later translation to 'actual' offsets. The AssemblerBuffer offsets
are directly usable now.
Remove tmpDataRelocations_, tmpPreBarriers_, and tmpJumpRelocations_.
The ARM64 assembler no longer needs to keep track of code offsets for
later translation to 'final' offsets. The AssemblerBuffer offsets are
directly usable now.
Remove tmpDataRelocations_, tmpPreBarriers_, tmpJumpRelocations_, and
the finalOffset() method.
This method was used by the Assembler::actualOffset() methods to
translate buffer offsets from pre-pool to post-pool numbers. Since
pools are now injected immediately, there is no need to translate
offsets.
All the actualOffset() methods have become no-ops in all our supported
targets.
This is possible because we no longer PodCopy the pools.
Use a more reasonable size for the inline memory in the loadOffsets
vector (8 loads instead of 512). This saves stack space when a
MacroAssembler is created on the stack. Use a matching inline size of 8
entries for the poolData array itself.
Don't drop memory in Pool::reset() by calling placement new - call
Vector::clear() instead which hangs on to previously allocated memory
for use by the next pool.
Delete an unused array of pools in arm64/vixl/MozBaseAssembler-vixl.h.
Use a Vector with 8 preallocated slots and a LifoAllocPolicy allocating
from the parent AssemblerBuffer's lifoAlloc_. We'll rarely need more
than 8 constant pools in a single assembler.
We can't actually allocate memory from this->lifoAlloc_ in the
constructor, but it is OK to capture allocator references like the
Vector constructor does.
Add an assertion to initWithAllocator() to verify that we didn't
allocate anything from lifoAlloc_ before the MacroAssembler constructor
had a chance to install an AutoJitContextAlloc.
There is no longer a 1-1 correspondence between buffer slices and
constant pools. We no longer need the ability to truncate a buffer
slice prematurely.
This uses less memory.
Since constant pools have been simplified such that they always follow
the load instructions referencing them, it is now possible to copy the
pool data into the main assembly buffer right away in finishPool()
instead of deferring the copy to executableCopy(). This has the
important effect that BufferOffset values don't need to be adjusted to
account for the size of injected constant pools.
- In finishPool(), copy the constant pool data into the main assembler
buffer with putBytesLarge() which allows the potentially large pool
data to be split over multiple slices.
- Stop copying pool data in executableCopy(). It has already
been copied in finishPool().
- Simplify the PoolInfo data structure to a simple (firstEntry, offset)
pair which records the necessary information about a single emitted
constant pool.
- Rewrite poolEntryOffset() to use the new PoolInfo data.
- Simplify poolSizeBefore() to just return 0. This function will be
removed entirely in a followup patch.
- Stop patching branches in executableCopy() and delete the
patchBranch() method. Since buffer offsets are reliable when the
branches are inserted and when labels are bound, there is no need to
adjust branches to account for constant pools.
- Delete the BufferSliceTail class. It is no longer necessary to
maintain a bit vector of branch instructions since we don't rewrite
branches any longer. Use the plain AssemblerBuffer::Slice class
instead.
This patch implements the basic functional change of copying pool data
immediately instead of deferring it. Followup patches will clean up the
now redundant code.
This new method copies a large amount of data into the assembler
buffer, potentially splitting it across multiple slices.
The existing putBytes() method can only copy into a single slice which
limits the maximum since of data that can be inserted and potentially
wastes space at the end of the previous slice.
The method IonCache::linkAndAttachStub() can run out of memory in a few
ways: When adding entries to the global jit code table, and when
generating code through the macro assembler.
Make sure to call ReportOutOfMemory() before returning false when that
happens. Otherwise we won't get the right of error reported, and OOM
simulation tests fail.
The Linker already calls ReportOutOfMemory(), so we don't need to
handle those calls.
