Rename Windows.h to WindowsSupport.h to avoid ambiguity

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201258 91177308-0d34-0410-b5e6-96231b3b80d8
Extend RTDyld API to enable optionally precomputing the total amount of memory
required for all sections in a module. This can be useful when targets or
code-models place strict requirements on how sections must be laid out
in memory.

If RTDyldMemoryManger::needsToReserveAllocationSpace() is overridden to return
true then the JIT will call the following method on the memory manager, which
can be used to preallocate the necessary memory.

void RTDyldMemoryManager::reserveAllocationSpace(uintptr_t CodeSize,
                                                 uintptr_t DataSizeRO,
                                                 uintptr_t DataSizeRW)

Patch by Vaidas Gasiunas. Thanks very much Viadas!



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201259 91177308-0d34-0410-b5e6-96231b3b80d8
Don't try to build ExceptionDemo on ARM.

The demo uses _Unwind_GetIP which is not available on that platform.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201261 91177308-0d34-0410-b5e6-96231b3b80d8
[Stackmaps] Fix the ID type to be i64 also for stackmaps (as we claim in the documenation)

The ID type for the stackmap and patchpoint intrinsics are in both cases i64.
This fixes an zero extend in the SelectionDAGBuilder that still used i32. This
also updates the target independent instructions STACKMAP and PATCHPOINT to use
the correct type.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201262 91177308-0d34-0410-b5e6-96231b3b80d8
[Stackmaps] Improve the stackmap lowering code in the SelectionDAGBuilder.

We are now no longer relying on the target-specific call lowering implementation
to lower a stackmap intrinsic call. Instead we perform the call lowering in a
target-independent way directly in the stackmap lowering code. This simplifies
the code and removes the need to fixup the code after the target-specific call
lowering.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201264 91177308-0d34-0410-b5e6-96231b3b80d8
Reformat a few lines with clang-format.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201265 91177308-0d34-0410-b5e6-96231b3b80d8
DebugInfo: Merge fission and non-fission (and 32 and 64 bit) tests for TLS support.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201266 91177308-0d34-0410-b5e6-96231b3b80d8
DebugInfo: Demonstrate that we're not currently uniquing address table entries in fission

Since I just discovered this while poking at other things, here's the
test case so I have it to come back to later.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201267 91177308-0d34-0410-b5e6-96231b3b80d8
VS Integration: install toolsets for x64 too (PR18738)

This does exactly the same thing as for Win32, except it passes -m64 to
the compiler and the files go in a different directory.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201269 91177308-0d34-0410-b5e6-96231b3b80d8
[X86] Teach the backend how to lower vector shift left into multiply rather than scalarizing it.

Instead of expanding a packed shift into a sequence of scalar shifts,
the backend now tries (when possible) to convert the vector shift into a
vector multiply.

Before this change, a shift of a MVT::v8i16 vector by a
build_vector of constants was always scalarized into a long sequence of "vector
extracts + scalar shifts + vector insert".
With this change, if there is SSE2 support, we emit a single vector multiply.

This change also affects SSE4.1, AVX, AVX2 shifts:
 - A shift of a MVT::v4i32 vector by a build_vector of non uniform constants
is now lowered when possible into a single SSE4.1 vector multiply.
 - Packed v16i16 shift left by constant build_vector are now expanded when
possible into a single AVX2 vpmullw.
This change also improves the lowering of AVX512f vector shifts.

Added test CodeGen/X86/vec_shift6.ll with some code examples that are affected
by this change.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201271 91177308-0d34-0410-b5e6-96231b3b80d8
[Vectorizer] Add a new 'OperandValueKind' in TargetTransformInfo called
'OK_NonUniformConstValue' to identify operands which are constants but
not constant splats.

The cost model now allows returning 'OK_NonUniformConstValue'
for non splat operands that are instances of ConstantVector or
ConstantDataVector.

With this change, targets are now able to compute different costs
for instructions with non-uniform constant operands.
For example, On X86 the cost of a vector shift may vary depending on whether
the second operand is a uniform or non-uniform constant.

This patch applies the following changes:
 - The cost model computation now takes into account non-uniform constants;
 - The cost of vector shift instructions has been improved in
   X86TargetTransformInfo analysis pass;
 - BBVectorize, SLPVectorizer and LoopVectorize now know how to distinguish
   between non-uniform and uniform constant operands.

Added a new test to verify that the output of opt
'-cost-model -analyze' is valid in the following configurations: SSE2,
SSE4.1, AVX, AVX2.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201272 91177308-0d34-0410-b5e6-96231b3b80d8
Remove a very old instcombine where we would turn sequences of selects into
logical operations on the i1's driving them.  This is a bad idea for every
target I can think of (confirmed with micro tests on all of: x86-64, ARM,
AArch64, Mips, and PowerPC) because it forces the i1 to be materialized into
a general purpose register, whereas consuming it directly into a select generally
allows it to exist only transiently in a predicate or flags register.

Chandler ran a set of performance tests with this change, and reported no
measurable change on x86-64.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201275 91177308-0d34-0410-b5e6-96231b3b80d8
The new MCJIT C-API unit test is generating objects without constant data
sections, at least on MachO. Relax expectations to keep the bots green while I
investigate. 



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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201279 91177308-0d34-0410-b5e6-96231b3b80d8
[CMake] llvm_add_library: Add handling of the parameter ADDITIONAL_HEADERS to pass through to process_source.

I was insightless then about unknown optional parameters.
(Consider that LINK_LIBS foo bar ADDITIONAL_HEADERS qux quux)

Suggested by Michael Kruse. Thanks!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201283 91177308-0d34-0410-b5e6-96231b3b80d8
GlobalOpt: Aliases don't have sections, don't copy them when replacing

As defined in LangRef, aliases do not have sections.  However, LLVM's
GlobalAlias class inherits from GlobalValue, which means we can read and
set its section.  We should probably ban that as a separate change,
since it doesn't make much sense for an alias to have a section that
differs from its aliasee.

Fixes PR18757, where the section was being lost on the global in code
from Clang like:

extern "C" {
__attribute__((used, section("CUSTOM"))) static int in_custom_section;
}

Reviewers: rafael.espindola

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201286 91177308-0d34-0410-b5e6-96231b3b80d8
[AArch64]Add support for spilling FPR8/FPR16.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201287 91177308-0d34-0410-b5e6-96231b3b80d8
Use simpler version of sys::fs::exists when possible.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201289 91177308-0d34-0410-b5e6-96231b3b80d8
[DAG] Fix the recognition of opaque constants in the SelectionDAGBuilder.

This fix checks the original LLVM IR node to identify opaque constants by
looking for the bitcast-constant pattern. Originally we looked at the generated
SDNode, but this might lead to incorrect results. The SDNode could have been
generated by an constant expression that was folded to a constant.

This fixes <rdar://problem/16050719>

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