llvm-svn: 211695

llvm-svn: 211694

llvm-svn: 211693

llvm-svn: 211692

Re-apply r211399, "Generate native unwind info on Win64" with a fix to ignore SEH pseudo ops in X86 JIT emitter.

--
This patch enables LLVM to emit Win64-native unwind info rather than
DWARF CFI.  It handles all corner cases (I hope), including stack
realignment.

Because the unwind info is not flexible enough to describe stack frames
with a gap of unknown size in the middle, such as the one caused by
stack realignment, I modified register spilling code to place all spills
into the fixed frame slots, so that they can be accessed relative to the
frame pointer.

Patch by Vadim Chugunov!

Reviewed By: rnk

Differential Revision: http://reviews.llvm.org/D4081

llvm-svn: 211691

llvm-svn: 211690

llvm-svn: 211689

32-bit: +ssse3
64-bit: +sse4.2 +popcnt

Differential Revision: http://reviews.llvm.org/D4287

llvm-svn: 211688

llvm-svn: 211687

The < 8 instead of <= 8 meant that a bunch of vreinterprets were not available on v8 AArch32. Simplify the guard to just !defined(aarch64) while we're at it, and enable some v8 AArch32 testing.

llvm-svn: 211686

llvm-svn: 211685

llvm-svn: 211684

Use existing DTLS code in sanitizer_tls_get_addr.{h,cc} to unpoison DTLS
blocks both on allocation and deallocation.

https://code.google.com/p/memory-sanitizer/issues/detail?id=44

llvm-svn: 211683

When looking through sections with zero-terminated string-literals (__cstring
or __ustring) we were constantly rechecking the first few bytes of the string
for '\0' rather than advancing along. This obviously failed unless all strings
within the section had the same length as that first one.

llvm-svn: 211682

We were trying to examine the first symbol in a section that we wanted to
atomize by symbols, even when there wasn't one. Instead, we should make the
initial anonymous symbol cover the entire section in that situation.

llvm-svn: 211681

Reviewed-by: Tom Stellard <tom@stellard.net>
llvm-svn: 211680

This patch teaches the backend how to combine a build_vector that implements
an 'addsub' between packed float vectors into a sequence of vector add
and vector sub followed by a VSELECT.

The new VSELECT is expected to be lowered into a BLENDI.
At ISel stage, the sequence 'vector add + vector sub + BLENDI' is
pattern-matched against ISel patterns added at r211427 to select
'addsub' instructions.
Added three more ISel patterns for ADDSUB.

Added test sse3-avx-addsub-2.ll to verify that we correctly emit 'addsub'
instructions.

llvm-svn: 211679

llvm-svn: 211678

The C++ language requires that the address of a function be the same
across all translation units.  To make __declspec(dllimport) useful,
this means that a dllimported function must also obey this rule.  MSVC
implements this by dynamically querying the import address table located
in the linked executable.  This means that the address of such a
function in C++ is not constant (which violates other rules).

However, the C language has no notion of ODR nor does it permit dynamic
initialization whatsoever.  This requires implementations to _not_
dynamically query the import address table and instead utilize a wrapper
function that will be synthesized by the linker which will eventually
query the import address table.  The effect this has is, to say the
least, perplexing.

Consider the following C program:
__declspec(dllimport) void f(void);

typedef void (*fp)(void);

static const fp var = &f;

const fp fun() { return &f; }

int main() { return fun() == var; }

MSVC will statically initialize "var" with the address of the wrapper
function and "fun" returns the address of the actual imported function.
This means that "main" will return false!

Note that LLVM's optimizers are strong enough to figure out that "main"
should return true.  However, this result is dependent on having
optimizations enabled!

N.B.  This change also permits the usage of dllimport declarators inside
of template arguments; they are sufficiently constant for such a
purpose.  Add tests to make sure we don't regress here.

llvm-svn: 211677

llvm-svn: 211676

Differential Revision: http://reviews.llvm.org/D4275

llvm-svn: 211675

dynamic symbol table populating and DT_NEEDED tag creation.

The `isDynSymEntryRequired` function returns true if the specified shared
library atom requires a dynamic symbol table entry. The `isNeededTagRequired`
function returns true if we need to create DT_NEEDED tag for the shared
library defined specified shared atom.

By default the both functions return true. So there is no functional changes
for all targets except MIPS. Probably we need to spread the same modifications
on other ELF targets but I want to implement and fully tested complete set of
changes for MIPS target first.

For MIPS we create a dynamic symbol table entry for a shared library atom iif
this atom is referenced by a regular defined atom. For example, if library L1
defines symbol T1, library L2 defines symbol T2 and uses symbol T1
and executable file E1 uses symbol T2 but does not use symbol T1 we create
an entry in the E1 dynamic symbol table for symbol T2 and do not create
an entry for T1.

The patch creates DT_NEEDED tags for shared libraries contain shared library
atoms which a) referenced by regular defined atoms; b) have corresponding
copy dynamic relocations (R_MIPS_COPY).

Now the patch does not take in account --as-needed / --no-as-needed command
line options. So it is too restrictive and create DT_NEEDED tags for really
needed shared libraries only. I plan to fix that by subsequent patches.

llvm-svn: 211674

Fixes exponential compilation complexity in PR19835, caused by
LICM::sink not handling the following pattern well:

f = op g
e = op f, g
d = op e
c = op d, e
b = op c
a = op b, c

When an instruction with N uses is sunk, each of its operands gets N
new uses (all of them - phi nodes). In the example above, if a had 1
use, c would have 2, e would have 4, and g would have 8.

llvm-svn: 211673

llvm-svn: 211672

Due to bad habit we sometimes used a variable %defaultOpts that listed
a set of passes commonly run to prepare for Polly. None of these test cases
actually needs special preparation and only two of them need the 'basicaa' to
be scheduled. Scheduling the required alias analysis explicitly makes the test
cases clearer.

llvm-svn: 211671

We had a set of test cases that have been incomplete and XFAILED. This patch
completes a couple of the interesting ones and removes the ones which seem
redundant or not sufficiently reduced to be useful.

llvm-svn: 211670

Not all supported compilers have GCC intrinsics, so this patch
uses the correct portable alternative.

Additionally, this patch fixes an off-by-one error.  __builtin_ffs
returns the 1-based index of the least-significant 1-bit, but the
function expects the base 2 logarithm of the number, which is
equivalent to the 0-based index of the least-significant 1-bit.

Reviewed by: Keno Fischer

Differential Revision: http://reviews.llvm.org/D4284

llvm-svn: 211669

llvm-svn: 211668

VarDecl provides a method getSourceRange(), which provides a more
robust way of getting the SourceRange since the TypeSourceInfo can
be null in certain cases.

Reviewed by: majnemer

Differential Revision: http://reviews.llvm.org/D4281

llvm-svn: 211667

The method was empty in the null streamer but I mistakenly replaced it with
the aborting one in MCStreamer.

llvm-svn: 211666

path using sub-strings concatenation. Return the whole string explicitly.

llvm-svn: 211665

MCNullStreamer.cpp: Roll back a few empty methods that have been marked as unreachable in MCStreamer.cpp.

  void EmitCOFFSecRel32(MCSymbol const *Symbol) override {}
  void EmitGPRel32Value(const MCExpr *Value) override {}

It should fix crash like "llc -mtriple=i686-cygwin -filetype=null".

llvm-svn: 211664

Tools.cpp: Update getLinuxDynamicLinker() to return Twine instead of StringRef, since r211598 has introduced manipulation of return string.

llvm-svn: 211663

llvm-svn: 211662

llvm-svn: 211661

llvm-svn: 211660

llvm-svn: 211659

to debugserver when launching processes.

<rdar://problem/16216199>

llvm-svn: 211658

Add predefined stdint macros that match the given patterns:

U?INT{_,_FAST,_LEAST}{8,16,32,64}_{MAX,TYPE}
U?INT{PTR,MAX}_{MAX,TYPE}

http://reviews.llvm.org/D4141

Author: binji
llvm-svn: 211657

Cleanup only.

llvm-svn: 211656