Fix r213824 on windows

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213866 91177308-0d34-0410-b5e6-96231b3b80d8
AArch64: refactor ReconstructShuffle function

Quite a bit of cruft had accumulated as we realised the various different cases
it had to handle and squeezed them in where possible. This refactoring mostly
flattens the logic and special-cases. The result is slightly longer, but I
think clearer.

Should be no functionality change.

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

Every user has been switched to using EngineBuilder.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213871 91177308-0d34-0410-b5e6-96231b3b80d8
Include relative path for header outside the current directory.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213872 91177308-0d34-0410-b5e6-96231b3b80d8
Let the integrated assembler understand .warning, PR20428.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213873 91177308-0d34-0410-b5e6-96231b3b80d8
Remove unused field MacroInstantiation::TheMacro. No behavior change.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213874 91177308-0d34-0410-b5e6-96231b3b80d8
Let the integrated assembler understand .exitm, PR20426.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213876 91177308-0d34-0410-b5e6-96231b3b80d8
R600: Add new functions for splitting vector loads and stores.

These will be used in future patches and shouldn't change anything yet.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213877 91177308-0d34-0410-b5e6-96231b3b80d8
X86: silence sign comparison warning

GCC 4.8 detected a signed compare [-Wsign-compare].  Add a cast for the
destination index.  Add an assert to catch a potential overflow however unlikely
it may be.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213878 91177308-0d34-0410-b5e6-96231b3b80d8
Try to fix the bots. If this does not work, I am going to move it to X86 directory.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213880 91177308-0d34-0410-b5e6-96231b3b80d8
R600: Add FMA instructions for Evergreen

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213882 91177308-0d34-0410-b5e6-96231b3b80d8
X86: correct library call setup for Windows itanium

This target is identical to the Windows MSVC (and follows Microsoft ABI for C).
Correct the library call setup for this target.  The same set of library calls
are missing on this environment.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213883 91177308-0d34-0410-b5e6-96231b3b80d8
Try to fix the bots again by moving test to X86 directory.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213884 91177308-0d34-0410-b5e6-96231b3b80d8
Use the same .eh_frame encoding for 32bit PPC as on i386.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213890 91177308-0d34-0410-b5e6-96231b3b80d8
Replace an assertion with a fatal error

Frontends are responsible for putting inalloca on parameters that would
be passed in memory and not registers.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213891 91177308-0d34-0410-b5e6-96231b3b80d8
[X86] Optimize stackmap shadows on X86.

This patch minimizes the number of nops that must be emitted on X86 to satisfy
stackmap shadow constraints.

To minimize the number of nops inserted, the X86AsmPrinter now records the
size of the most recent stackmap's shadow in the StackMapShadowTracker class,
and tracks the number of instruction bytes emitted since the that stackmap
instruction was encountered. Padding is emitted (if it is required at all)
immediately before the next stackmap/patchpoint instruction, or at the end of
the basic block.

This optimization should reduce code-size and improve performance for people
using the llvm stackmap intrinsic on X86.

<rdar://problem/14959522>



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213892 91177308-0d34-0410-b5e6-96231b3b80d8
Windows: Don't wildcard expand /? or -?

Even if there's a file called c:\a, we want /? to be preserved as
an option, not expanded to a filename.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213894 91177308-0d34-0410-b5e6-96231b3b80d8
Feedback from Hans on r213815. No functionaility change.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213895 91177308-0d34-0410-b5e6-96231b3b80d8
Target: invert condition for Windows

The Microsoft ABI and MSVCRT are considered the canonical C runtime and ABI.
The long double routines are not part of this environment.  However, cygwin and
MinGW both provide supplementary implementations.  Change the condition to
reflect this reality.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213896 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Make vector legalization of extloads work more like the "normal"
vector operation legalization with support for custom target lowering
and fallback to expand when it fails, and use this to implement sext and
anyext load lowering for x86 in a more principled way.

Previously, the x86 backend relied on a target DAG combine to "combine
away" sextload and extload nodes prior to legalization, or would expand
them during legalization with terrible code. This is particularly
problematic because the DAG combine relies on running over non-canonical
DAG nodes at just the right time to match several common and important
patterns. It used a combine rather than lowering because we didn't have
good lowering support, and to expose some tricks being employed to more
combine phases.

With this change it becomes a proper lowering operation, the backend
marks that it can lower these nodes, and I've added support for handling
the canonical forms that don't have direct legal representations such as
sextload of a v4i8 -> v4i64 on AVX1. With this change, our test cases
for this behavior continue to pass even after the DAG combiner beigns
running more systematically over every node.

There is some noise caused by this in the test suite where we actually
use vector extends instead of subregister extraction. This doesn't
really seem like the right thing to do, but is unlikely to be a critical
regression. We do regress in one case where by lowering to the
target-specific patterns early we were able to combine away extraneous
legal math nodes. However, this regression is completely addressed by
switching to a widening based legalization which is what I'm working
toward anyways, so I've just switched the test to that mode.

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

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