Add x86_64 code generation support

Utilizes r0..r7 in register allocator, implements spill/unsill
core regs as well as operations with stack pointer.

Change-Id: I973d5a1acb9aa735f6832df3d440185d9e896c67
Signed-off-by: Dmitry Petrochenko <dmitry.petrochenko@intel.com>
ART: A Compile Filter for x86_64

This patch enables an x86_64 compile filter for everything
we're not ready to compile right now.

Signed-off-by: Vladimir Kostyukov <vladimir.kostyukov@intel.com>
Change-Id: I9ba87cf7f05e3465f12fd16a87b54f9649baf88a
dalvikvm: create the dalvikvm symlink to the primary version

use executable_prefer_symlink.mk to create the dalvikvm symlink
to the primary version of dalvikvm command.
So that the modules call dalvikvm command don't need to change again.

Change-Id: Ie5cefc26dc90fb56c35b6b9e4537eda126f61ea1
Signed-off-by: Yongqin Liu <yongqin.liu@linaro.org>
ART: Resolve MAP_32BIT limitation in x86_64

Add checks that ensure when low4gb is set and an expected pointer
is given the requested memory fits into 4GB.

On x86_64, only use MAP_32BIT when there is no expected pointer.
This avoids a limitation in mmap (only 2GB visible).

Add tests to check behavior.

Original Author: Qiming Shi <qiming.shi@intel.com>
Change-Id: Ia2e3e0a46764ef70126b0c264f1fae681622d3cb
Merge "ART: Resolve MAP_32BIT limitation in x86_64"
Fix JDWP location event report on return instructions

After change https://android-review.googlesource.com/94334, the debugger may
listen to kDexPcChange event without listening for kMethodExit event. In this
case, we need to report kDexPcChange event on RETURN instructions.

Bug: 11874828
Change-Id: Ic61f4eec71e7ece494bee628d7f3358a616d31d3
Don't import llvm.mk for non-portable builds.

Change-Id: I447e7d816c0e4f84bc4d13bc34ff93b026d192b5
Fix CompilationUnit constructor issues.

Ensure target64 is initialized. Switch from NULL to nullptr as the former gives
compilation errors with std::unique_ptr from libc++.

Change-Id: I7153368d9324d10ef257f7c7ce9571a1753e5ba8
Merge "Fix CompilationUnit constructor issues."
Improve large object free CHECK

The new CHECK prints the address of the object.

Bug: 14974497

Change-Id: I8e9e9f66767a220330cc77ef6549529bb2ac4112
Merge "Improve large object free CHECK"
Declare variable for all art oat tests

Change-Id: If0795928ab08bbce80479eec32b987662631b8cf
Merge "Declare variable for all art oat tests"
Merge "Don't import llvm.mk for non-portable builds."
Workaround x86 interpretter stack overflow

Bug: 14982147
Change-Id: I5fa5c30dbac7e50dd6dd7c8d12bbc769c0dfc150
Move RoS allocator to use unordered_set.

Work-around existing stlport issues for the target. This will go away when the
target is using libc++.

Change-Id: I8f213ecd9dc7d93d17f4a0d7e84182c12af6ca1b
ART: Fix MonitorExit code on ARM

We do not emit barriers on non-SMP systems. But on ARM, we have
places that need to conditionally execute, which is done through
an IT instruction. The guide of said instruction thus changes
between SMP and non-SMP systems.

To cleanly approach this, change the API so that GenMemBarrier
returns whether it generated an instruction. ARM will have to
query the result and update any dependent IT.

Throw a build system error if TARGET_CPU_SMP is not set.

Fix runtime/Android.mk to work with new multilib host.

Bug: 14989275
Change-Id: I9e611b770e8a1cd4ca19367d7dae0573ec08dc61
Merge "ART: Fix MonitorExit code on ARM"
Quick Compiler: fix Arm cts failures

Fixes move_wide_16#testN1, move_wide_16#testN2

Two bugs for the price of one (thanks CTS!)

First, the new stack overflow checking code was broken for very
large frames.  For Arm on method entry, we only have 1 available
temp register, r12, until argument registers are flushed.
Previously, for explicit checks on large frames,
r12 was immediately loaded with the stack_end value.  However,
later on when the frame is extended, if the frame size exceeds
the range of a reg-reg-imm subtract, the codegen utilities will
allocate a new temporary register to complete the operation. r12
was getting clobbered.  Similarly, for medium-large frames r12
could get clobbered during frame creation.

What we should always do when directly using fixed registers like
this is to lock them to prevent them from being allocated as a
temp.  The other half of the first bug is easily solved by delaying
the load of stack_end until after the new sp is computed.  We'll
increase the stall cost, but this is an uncommon case.

The second bug was likely a typo in LoadValueDisp().  I'm a bit
surprised we hadn't hit this one earlier - but perhaps it was
recently introduced.  The wrong base register was being used in
the non-float, wide, excessive offset case (which I suppose is also
somewhat uncommon).

Cherry-pick of internal commit If5b30f729e31d86db604045dd7581fd4626e0b55

Change-Id: If5b30f729e31d86db604045dd7581fd4626e0b55
Merge "Quick Compiler: fix Arm cts failures"