| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The algorithm of ParallelMoveResolverNoSwap() is almost the same with
ParallelMoveResolverWithSwap(), except the way we resolve the circular
dependency. NoSwap() uses additional scratch register to resolve the
circular dependency. For example, (0->1) (1->2) (2->0) will be performed
as (2->scratch) (1->2) (0->1) (scratch->0).
On architectures without swap register support, NoSwap() can reduce the
number of moves from 3x(N-1) to (N+1) when there is circular dependency
with N moves.
And also, NoSwap() algorithm does not depend on architecture register
layout information, which means it can support register pairs on arm32
and X/W, D/S registers on arm64 without additional modification.
Change-Id: Idf56bd5469bb78c0e339e43ab16387428a082318
|
| |
|
|
|
|
|
|
|
| |
The ParallelMoveResolver implementation needs to know if a move
is for 64bits or not, to handle swaps correctly.
Bug found, and test case courtesy of Serguei I. Katkov.
Change-Id: I9a0917a1cfed398c07e57ad6251aea8c9b0b8506
|
| |
|
|
|
|
|
|
|
|
| |
Registers involved in single and double operations can
drag stack locations as well, so it is possible to update
a single stack location with a slot from a double stack location.
bug:19999189
Change-Id: Ibeec7d6f1b3126c4ae226fca56e84dccf798d367
|
| |
|
|
| |
Change-Id: I806ec522b979334cee8f344fc95e8660c019160a
|
| |
|
|
|
|
|
|
|
|
| |
Moved arena pool into the runtime.
Motivation:
Allow GC to use arena allocators, recycle arena pool for linear alloc.
Bug: 19264997
Change-Id: I8ddbb6d55ee923a980b28fb656c758c5d7697c2f
|
| |
|
|
| |
Change-Id: Ie2a540ffdb78f7f15d69c16a08ca2d3e794f65b9
|
| |
|
|
|
|
|
| |
The ParallelMoveResolver does not work with pairs. Instead,
decompose the pair into two individual moves.
Change-Id: Ie9d3f0b078cef8dc20640c98b20bb20cc4971a7f
|
| |
|
|
|
|
|
|
| |
It does not make sense to have moves to the same destination
within a single parallel move. There is now an explicit
DCHECK to prevent these situations.
Change-Id: I3a33e748579ecb53b95476e77a37164d2f145f5a
|
| |
|
|
|
|
|
|
| |
This fixes the case where a constant move requires a scratch
register. Note that there is no backend that needs this for now,
but X86 might with the move to hard float.
Change-Id: I37f6b8961b48f2cf6fbc0cd281e70d58466d018e
|
| |
|
|
|
|
|
|
|
|
|
| |
Fix associated errors about unused paramenters and implict sign conversions.
For sign conversion this was largely in the area of enums, so add ostream
operators for the effected enums and fix tools/generate-operator-out.py.
Tidy arena allocation code and arena allocated data types, rather than fixing
new and delete operators.
Remove dead code.
Change-Id: I5b433e722d2f75baacfacae4d32aef4a828bfe1b
|
| |
|
|
|
|
|
| |
Now the source of truth is the Location object that knows
which register (core, pair, fpu) it needs to refer to.
Change-Id: I62401343d7479ecfb24b5ed161ec7829cda5a0b1
|
| |
|
|
|
|
|
|
|
|
|
|
| |
To make sure we do not connect interval siblings in the
same parallel move, I added a new field in MoveOperands
that tells for which instruction this move is for.
A parallel move should not contains moves for the same instructions.
The checks revealed a bug when connecting siblings, where
we would choose the wrong parallel move.
Change-Id: I70f27ec120886745c187071453c78da4c47c1dd2
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This CL implements:
1) Resolution after allocation: connecting the locations
allocated to an interval within a block and between blocks.
2) Handling of fixed registers: some instructions require
inputs/output to be at a specific location, and the allocator
needs to deal with them in a special way.
3) ParallelMoveResolver::EmitNativeCode for x86.
Change-Id: I0da6bd7eb66877987148b87c3be6a983b4e3f858
|
|
|
And write a few tests while at it.
A parallel move resolver will be needed for performing multiple moves
that are conceptually parallel, for example moves at a block
exit that branches to a block with phi nodes.
Change-Id: Ib95b247b4fc3f2c2fcab3b8c8d032abbd6104cd7
|
