tree 98f1125db961451699880019c8663d76e7b94d02
parent 1580379bb02ee7866ca94d54851a4d08de12a5a4
author Shih-wei Liao <sliao@google.com> 1331445351 -0800
committer Shih-wei Liao <sliao@google.com> 1331659611 -0700

Fix the LLVM build. Separate out libart-compiler-llvm.so.

After this refactoring:
If (!USE_LLVM_COMPILER), I pass the test-art and boot the phone alright.
The behavior is the same for non-LLVM builds as before. Multi-target
art-compiler shared libraries are generated as before.
If (USE_LLVM_COMPILER), I generate libart-compiler-llvm.so successfully.

Note that the ideal refactoring for the next step will be to always build
art-compiler and LLVM-[arm|mips|x86] shared libraries. Currently, we
haven't removed all the ifdefs for libart.so yet, so this is not ideal yet.
Reason for not-done-yet is that the next step requires discussions.
I can remove all the ifdefs today, but then the (!USE_LLVM_COMPILER)
build will incur extra fields and overhead.

This refactoring allows us to restore the LLVM build situation to be before
the breakage yesterday, so we can continue making forward progress again.

One difficulty in the refactoring is that LLVM is not a method compiler
in default, unlike (!USE_LLVM_COMPILER). LLVM actually compiles an LLVM module
at a time normally. So we need to do more call backs and tell
libart-compiler-llvm.so in each invocation where we are in terms of
OatCompilationUnit.

Another difficulty is that currently our LLVM compiler is not
multithreaded and requires locking, unlike (!USE_LLVM_COMPILER). So more
callbacks are needed. This will be fixed when we fix the multithreading
issue.

Change-Id: I93bce21b6d673254188f2a60b1a7f91b508e497f