As with global accesses, external functions could exist anywhere in
memory. Therefore the stub must create a complete 64-bit address. This
patch implements the fragment as (roughly):
    movz x16, #:abs_g3:somefunc
    movk x16, #:abs_g2_nc:somefunc
    movk x16, #:abs_g1_nc:somefunc
    movk x16, #:abs_g0_nc:somefunc
    br x16

In principle we could save 4 bytes by using a literal-load instead,
but it is unclear that would be more efficient and can only be tested
when real hardware is readily available.

This allows (for example) the MCJIT test 2003-05-07-ArgumentTest to
pass on AArch64.

llvm-svn: 181133

The large memory model (default and main viable for JIT) emits
addresses in need of relocation as
    movz x0, #:abs_g3:somewhere
    movk x0, #:abs_g2_nc:somewhere
    movk x0, #:abs_g1_nc:somewhere
    movk x0, #:abs_g0_nc:somewhere

To support this we must implement those four relocations in the
dynamic loader.

This allows (for example) the test-global.ll MCJIT test to pass on
AArch64.

llvm-svn: 181132

R_AARCH64_PCREL32 is present in even trivial .eh_frame sections and so
is required to compile any function without the "nounwind" attribute.

This change implements very basic infrastructure in the RuntimeDyldELF
file and allows (for example) the test-shift.ll MCJIT test to pass
on AArch64.

llvm-svn: 181131

These changes just allow AArch64 to take part in the MCJIT world when
built correctly.

llvm-svn: 181130

AArch64 is going to need some kind of cache-invalidation in order to
successfully JIT since it has a weak memory-model. This is provided by
a __clear_cache builtin in libgcc, which acts very much like the
32-bit ARM equivalent (on platforms where it exists).

llvm-svn: 181129

operand types.

llvm-svn: 181128

llvm-svn: 181127

This let us to remove some custom code that matched constant offsets
from globals at instruction selection time as a special addressing mode.
No intended functionality change.

llvm-svn: 181126

The code now makes use of ComputeMaskedBits,
SelectionDAG::isBaseWithConstantOffset and TargetLowering::isGAPlusOffset
where appropriate reducing the amount of logic needed in XCoreISelLowering.
No intended functionality change.

llvm-svn: 181125

Thread local storage is not supported by the XMOS linker so we handle
thread local variables by lowering the variable to an array of n elements
(where n is the number of hardware threads per core, currently 8
for all XMOS devices) indexed by the the current thread ID.

Previously this lowering was spread across the XCoreISelLowering and the
XCoreAsmPrinter classes. Moving this to a separate pass should be much
cleaner.

llvm-svn: 181124

Properly parsing __declspec(safebuffers), though there is no semantic hookup.  For more information about safebuffers, see MSDN: http://msdn.microsoft.com/en-us/library/dd778695(v=vs.110).aspx

llvm-svn: 181123

llvm-svn: 181122

Supporting TLS in the large memory model is rather difficult at the
moment, so make sure no-one gets into difficulties by mistake.

llvm-svn: 181121

llvm-svn: 181120

llvm-svn: 181119

llvm-svn: 181118

The MOVZ/MOVK instruction sequence may not be the most efficient (a
literal-pool load could be better) but adding that would require
reinstating the ConstantIslands pass.

For now the sequence is correct, and that's enough. Beware, as of
commit GNU ld does not appear to support the relocations needed for
this. Its primary purpose (for now) will be to support JITed code,
since in that case there is no guarantee of where your code will end
up in memory relative to external symbols it references.

llvm-svn: 181117

This allows us to get get rid of a hack in XCoreTargetObjectFile where the
the DataRel* sections were overridden.

llvm-svn: 181116

and specified the triple.

llvm-svn: 181115

No functionality change.

llvm-svn: 181114

llvm-svn: 181113

The intended semantics mirror autoconf, where the user is able to
specify a host triple, but if it's left to the build system then
"config.guess" is invoked for the default.

This also renames the LLVM_HOSTTRIPLE define to LLVM_HOST_TRIPLE to
fit in with the style of the surrounding defines.

llvm-svn: 181112

libgcc provides a __clear_cache intrinsic on AArch64, much like it
does on 32-bit ARM.

llvm-svn: 181111

and mark "clarifying memory allocation" as done, since it turns out that our
optimizations here (such as they are) already conform to the new rules.

llvm-svn: 181110

llvm-svn: 181109

Missing (somewhat ironically) is support for the new deduction rules
in lambda functions, plus PCH support for return type patching.

llvm-svn: 181108

to use. This makes very little difference right now (other than suppressing
follow-on errors in some cases), but will matter more once we support deduced
return types (we don't want expressions with undeduced return types in the
AST).

llvm-svn: 181107

to not let it update the thread list or else we'll infinite recurse
call back to UpdateThreadList.

llvm-svn: 181106

This takes the linking of almost all modules in a clang build from 6:32
to 0:19.

llvm-svn: 181105

Now that we hava a convinient place to keep it, remeber the set of
identified structs as we merge modules.

This speeds up the linking of all the bitcode files in clang with the
gold plugin and -plugin-opt=emit-llvm (i.e., link only, no codegen) from
5:25 minutes to 13.6 seconds!

Patch by Xiaofei Wan!

llvm-svn: 181104

llvm-svn: 181103

Flipping which one is the implementation will let us optimize linkInModule.

llvm-svn: 181102

- Sema tests added and CodeGen tests are pending

Differential Revision: http://llvm-reviews.chandlerc.com/D728

llvm-svn: 181101

Also remove unused includes.

llvm-svn: 181100

Update comments, fix * placement, fix method names that are not
used in clang, add a linkInModule that takes a Mode and put it
in Linker.cpp.

llvm-svn: 181099

The linker is now responsible only for actually linking the modules, it
is up to the clients to create and destroy them.

llvm-svn: 181098

llvm-svn: 181097

llvm-svn: 181096

llvm-svn: 181095

llvm-svn: 181094