X86AsmPrinter MCJIT MSVC bug fix.

Summary:
This bug was introduced in r213006 which makes an assumption that MCSection is COFF for Windows MSVC. This assumption is broken for MCJIT users where ELF is used instead [1]. The fix is to change the MCSection cast to a dyn_cast.

[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-December/068407.html.

Reviewers: majnemer

Reviewed By: majnemer

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216173 91177308-0d34-0410-b5e6-96231b3b80d8
Move DisableGVNLoadPRE from populateLTOPassManager to PassManagerBuilder.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216174 91177308-0d34-0410-b5e6-96231b3b80d8
DAGCombiner: Make concat_vector combine safe for EVTs and concat_vectors with many arguments.

PR20677

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216175 91177308-0d34-0410-b5e6-96231b3b80d8
[CLNUP] Remove return after llvm_unreachable. Thanks to Hal Finkel for pointing.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216176 91177308-0d34-0410-b5e6-96231b3b80d8
Handle inlining in populateLTOPassManager like in populateModulePassManager.

No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216178 91177308-0d34-0410-b5e6-96231b3b80d8
Add a thread-model knob for lowering atomics on baremetal & single threaded systems

http://reviews.llvm.org/D4984


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216182 91177308-0d34-0410-b5e6-96231b3b80d8
[FastISel][AArch64] Remove redundant test.

These tests and many more are already covered by fast-isel-addressing-modes.ll.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216186 91177308-0d34-0410-b5e6-96231b3b80d8
Use returns_nonnull in BumpPtrAllocator and MallocAllocator to avoid null-check in placement new

In both Clang and LLVM, this is a common pattern:

  Size = sizeof(DeclRefExpr) + SomeExtraStuff;
  void *Mem = Context.Allocate(Size, llvm::alignOf<DeclRefExpr>());
  return new (Mem) DeclRefExpr(...);

The annoying thing is that because the default placement-new operator has a
nothrow specification, the compiler will insert a null check of Mem before
calling the DeclRefExpr constructor. This null check is redundant for us,
because we expect the allocation functions to never return null.

By annotating the allocator functions with returns_nonnull, we can optimize
away these checks. Compiling clang with a recent version of Clang and measuring
with:

  $ perf stat -r20 bin/clang.patch -fsyntax-only -w gcc.c && perf stat -r20 bin/clang.orig -fsyntax-only -w gcc.c

Shows a 2.4% speed-up (+- 0.8%).

The pattern occurs in LLVM too. Measuring with -O3 (and now using bzip2.c
instead, because it's smaller):

  $ perf stat -r20 bin/clang.patch -O3 -w bzip2.c  &&  perf stat -r20 bin/clang.orig -O3 -w bzip2.c

Shows 4.4 % speed-up (+- 1%).

If anyone knows of a similar attribute we can use for MSVC, or some other
technique to get rid off the null check there, please let me know.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216192 91177308-0d34-0410-b5e6-96231b3b80d8
Thumb1 load/store optimizer: Improve code to materialize new base register.

There are two add-immediate instructions in Thumb1: tADDi8 and tADDi3. Only
the latter supports using different source and destination registers, so
whenever we materialize a new base register (at a certain offset) we'd do
so by moving the base register value to the new register and then adding in
place. This patch changes the code to use a single tADDi3 if the offset is
small enough to fit in 3 bits.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216193 91177308-0d34-0410-b5e6-96231b3b80d8
[FastISel][AArch64] Factor out ANDWri instruction generation into a helper function. NFCI.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216199 91177308-0d34-0410-b5e6-96231b3b80d8
[AArch64] Run a peephole pass right after AdvSIMD pass.
The AdvSIMD pass may produce copies that are not coalescer-friendly. The
peephole optimizer knows how to fix that as demonstrated in the test case.

<rdar://problem/12702965>


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216200 91177308-0d34-0410-b5e6-96231b3b80d8
Remove dead code. NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216201 91177308-0d34-0410-b5e6-96231b3b80d8
Respect LibraryInfo in populateLTOPassManager and use it. NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216203 91177308-0d34-0410-b5e6-96231b3b80d8
[LIT] Remove documentation for  method since it does not exist

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216204 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-gcc is dead.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216206 91177308-0d34-0410-b5e6-96231b3b80d8
Coverage Mapping: add function's hash to coverage function records.

The profile data format was recently updated and the new indexing api
requires the code coverage tool to know the function's hash as well
as the function's name to get the execution counts for a function.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216207 91177308-0d34-0410-b5e6-96231b3b80d8
[AVX512] Add class to group common template arguments related to vector type

We discussed the issue of generality vs. readability of the AVX512 classes
recently.  I proposed this approach to try to hide and centralize the mappings
we commonly perform based on the vector type.  A new class X86VectorVTInfo
captures these.

The idea is to pass an instance of this class to classes/multiclasses instead
of the corresponding ValueType.  Then the class/multiclass can use its field
for things that derive from the type rather than passing all those as separate
arguments.

I modified avx512_valign to demonstrate this new approach.  As you can see
instead of 7 related template parameters we now have one.  The downside is
that we have to refer to fields for the derived values.  I named the argument
'_' in order to make this as invisible as possible.  Please let me know if you
absolutely hate this.  (Also once we allow local initializations in
multiclasses we can recover the original version by assigning the fields to
local variables.)

Another possible use-case for this class is to directly map things, e.g.:

  RegisterClass KRC = X86VectorVTInfo<32, i16>.KRC

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216209 91177308-0d34-0410-b5e6-96231b3b80d8
Move some logic to populateLTOPassManager.

This will avoid code duplication in the next commit which calls it directly
from the gold plugin.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216211 91177308-0d34-0410-b5e6-96231b3b80d8
Satiate the sanitizer build bot

This fixes a missing initializer from r216182


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216212 91177308-0d34-0410-b5e6-96231b3b80d8
Rewrite the gold plugin to fix pr19901.

There is a fundamental difference between how the gold API and lib/LTO view
the LTO process.

The gold API talks about a particular symbol in a particular file. The lib/LTO
API talks about a symbol in the merged module.

The merged module is then defined in terms of the IR semantics. In particular,
a linkonce_odr GV is only copied if it is used, since it is valid to drop
unused linkonce_odr GVs.

In the testcase in pr19901 both properties collide. What happens is that gold
asks us to keep a particular linkonce_odr symbol, but the IR linker doesn't
copy it to the merged module and we never have a chance to ask lib/LTO to keep
it.

This patch fixes it by having a more direct implementation of the gold API. If
it asks us to keep a symbol, we change the linkage so it is not linkonce. If it
says we can drop a symbol, we do so. All of this before we even send the module
to lib/Linker.

Since now we don't have to produce LTO_SYMBOL_SCOPE_DEFAULT_CAN_BE_HIDDEN,
during symbol resolution we can use a temporary LLVMContext and do lazy
module loading. This allows us to keep the minimum possible amount of
allocated memory around. This should also allow as much parallelism as
we want, since there is no shared context.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216215 91177308-0d34-0410-b5e6-96231b3b80d8