R600/SI: Fix fmin_legacy / fmax_legacy matching for SI

select_cc is expanded on SI, so this was never matched.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221941 91177308-0d34-0410-b5e6-96231b3b80d8
Silence MSVC warning on missing return after fully covered switch

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221943 91177308-0d34-0410-b5e6-96231b3b80d8
Relax the gcov version.ll test to check '.' instead of '\*'

The escaping of the '\*' doesn't work with my combination of testing
tools.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221944 91177308-0d34-0410-b5e6-96231b3b80d8
ADT: Use perfect forwarding in StringMapEntry::Create()

Now you can pass references into constructors.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221946 91177308-0d34-0410-b5e6-96231b3b80d8
Fix symbol resolution of floating point libc builtins in MCJIT

Fix for LLI failure on Windows\X86: http://llvm.org/PR5053

LLI.exe crashes on Windows\X86 when single precession floating point
intrinsics like the following are used: acos, asin, atan, atan2, ceil,
copysign, cos, cosh, exp, floor, fmin, fmax, fmod, log, pow, sin, sinh,
sqrt, tan, tanh

The above intrinsics are defined as inline-expansions in math.h, and are
not exported by msvcr120.dll (Win32 API GetProcAddress returns null).

For an FREM instruction, the JIT compiler generates a call to a stub for
the fmodf() intrinsic, and adds a relocation to fixup at load time. The
loader searches the libraries for the function, but fails because the
symbol is not exported. So, the call target remains NULL and the
execution crashes.

Since the math functions are loaded at JIT/runtime, the JIT can patch
CALL instruction directly instead of the searching the libraries'
exported symbols.  However, this fix caused build failures due to
unresolved symbols like _fmodf at link time.

Therefore, the current fix defines helper functions in the Runtime
link/load library to perform the above operations.  The address of these
helper functions are used to patch up the CALL instruction at load time.

Reviewers: lhames, rnk

Reviewed By: rnk

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

Patch by Swaroop Sridhar!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221947 91177308-0d34-0410-b5e6-96231b3b80d8
First stage of call lowering for Mips fast-isel

Summary:
This has most of what is needed for mips fast-isel call lowering for O32.
What is missing I will add on the next patch because this patch is already too large.
It should not be doing anything wrong but it will punt on some cases that it is basically
capable of doing.

The mechanism is there for parameters to be passed on the stack but I have not enabled it because it serves as a way for now to prevent some of the strange cases of O32 register passing that I have not fully checked yet and have some issues.

The Mips O32 abi rules are very complicated as far how data is passed in floating and integer registers.

However there is a way to think about this all very simply and this implementation reflects that.

Basically, the ABI rules are written as if everything is passed on the stack and aligned as such.
Once that is conceptually done, it is nearly trivial to reassign those locations to registers and
then all the complexity disappears.

So I have told tablegen that all the data is passed on the stack and during the lowering I fix
this by assigning to registers as per the ABI doc.

This has been my approach and you can line up what I did with the ABI document and see 1 to 1 what
is going on.



Test Plan: callabi.ll

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: jholewinski, echristo, ahatanak, llvm-commits, rfuhler

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221948 91177308-0d34-0410-b5e6-96231b3b80d8
Fix the VS 2012 build

VS 2012 doesn't have fminf or fmaxf.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221949 91177308-0d34-0410-b5e6-96231b3b80d8
IR: Make MDString::getName() private

Hide the fact that `MDString`'s string is stored in `Value::Name` --
that's going to change soon.  Update the only in-tree client that was
using it instead of `Value::getString()`.

Part of PR21532.

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