llvm-svn: 181146

X86ISelLowering has support to treat:
(icmp ne (and (xor %flags, -1), (shl 1, flag)), 0)

as if it were actually:
(icmp eq (and %flags, (shl 1, flag)), 0)

However, r179386 has code at the InstCombine level to handle this.

llvm-svn: 181145

Add support for min/max reductions when "no-nans-float-math" is enabled. This
allows us to assume we have ordered floating point math and treat ordered and
unordered predicates equally.

radar://13723044

llvm-svn: 181144

Add support for matching 'ordered' and 'unordered' floating point min/max
constructs.

In LLVM we can express min/max functions as a combination of compare and select.
We have support for matching such constructs for integers but not for floating
point. In floating point math there is no total order because of the presence of
'NaN'. Therefore, we have to be careful to preserve the original fcmp semantics
when interpreting floating point compare select combinations as a minimum or
maximum function. The resulting 'ordered/unordered' floating point maximum
function has to select the same value as the select/fcmp combination it is based
on.

 ordered_max(x,y)   = max(x,y) iff x and y are not NaN, y otherwise
 unordered_max(x,y) = max(x,y) iff x and y are not NaN, x otherwise
 ordered_min(x,y)   = min(x,y) iff x and y are not NaN, y otherwise
 unordered_min(x,y) = min(x,y) iff x and y are not NaN, x otherwise

This matches the behavior of the underlying select(fcmp(olt/ult/.., L, R), L, R)
construct.

Any code using this predicate has to preserve this semantics.

A follow-up patch will use this to implement floating point min/max reductions
in the vectorizer.

radar://13723044

llvm-svn: 181143

No need for setting the operands. The pointers are going to be bound by the
matcher.

radar://13723044

llvm-svn: 181142

We can just use the initial element that feeds the reduction.

  max(max(x, y), z) == max(max(x,y), max(x,z))

radar://13723044

llvm-svn: 181141

Patch by Robert Wilhelm.

llvm-svn: 181138

llvm-svn: 181137

llvm-svn: 181136

This removes dire warnings about AArch64 being unsupported and enables
the tests when appropriate on this platform.

llvm-svn: 181135

This is about the simplest relocation, but surprisingly rare in actual
code.

It occurs in (for example) the MCJIT test test-ptr-reloc.ll.

llvm-svn: 181134

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

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

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

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

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

llvm-svn: 181102

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

llvm-svn: 181090

llvm-svn: 181082