Fix several bugs in r221220's new program finding code.

In both the Unix and Windows variants, std::getenv was called and the
result passed directly to a function accepting a StringRef. This isn't
OK because it might return a null pointer and that causes the StringRef
constructor to assert (and generally produces crash-prone code if
asserts are disabled). Fix this by independently testing the result as
non-null prior to splitting things.

This in turn uncovered another bug in the Unix variant where it would
infinitely recurse if PATH="", or after this fix if PATH isn't set.
There is no need to recurse at all. Slightly re-arrange the code to make
it clear that we can just fixup the Paths argument based on the
environment if we find anything.

I don't know of a particularly useful way to test these routines in
LLVM. I'll commit a test to Clang that ensures that its driver correctly
handles various settings of PATH. However, I have no idea how to
correctly write a Windows test for the PATHEXT change. Any Windows
developers who could provide such a test, please have at. =D

Many thanks to Nick Lewycky and others for helping debug this. =/ It was
quite nasty for us to track down.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223099 91177308-0d34-0410-b5e6-96231b3b80d8
Fix variable used only in assertion.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223101 91177308-0d34-0410-b5e6-96231b3b80d8
[signext.ll] Removal Of Duplicate Test Cases

Removed the duplicate test case existing in signext.ll file.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223109 91177308-0d34-0410-b5e6-96231b3b80d8
Emit Tag_ABI_FP_denormal correctly in fast-math mode.

The default ARM floating-point mode does not support IEEE 754 mode exactly. Of
relevance to this patch is that input denormals are flushed to zero. The way in
which they're flushed to zero depends on the architecture,

  * For VFPv2, it is implementation defined as to whether the sign of zero is
    preserved.
  * For VFPv3 and above, the sign of zero is always preserved when a denormal
    is flushed to zero.

When FP support has been disabled, the strategy taken by this patch is to
assume the software support will mirror the behaviour of the hardware support
for the target *if it existed*. That is, for architectures which can only have
VFPv2, it is assumed the software will flush to positive zero. For later
architectures it is assumed the software will flush to zero preserving sign.

Change-Id: Icc5928633ba222a4ba3ca8c0df44a440445865fd

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223110 91177308-0d34-0410-b5e6-96231b3b80d8
Add ARM relocations to ELFYAML

Tested with check-all with no regressions.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223112 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for ARM modified-immediate assembly syntax.

Certain ARM instructions accept 32-bit immediate operands encoded as a 8-bit
integer value (0-255) and a 4-bit rotation (0-30, even). Current ARM assembly
syntax support in LLVM allows the decoded (32-bit) immediate to be specified
as a single immediate operand for such instructions:

mov r0, #4278190080

The ARMARM defines an extended assembly syntax allowing the encoding to be made
more explicit, as in:

mov r0, #255, #8 ; (same 32-bit value as above)

The behaviour of the two instructions can be different w.r.t flags, which is
documented under "Modified immediate constants" in ARMARM. This patch enables
support for this extended syntax at the MC layer.

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

Removing an unused function which is causing one of the build bots to fail.
This was introduced in the commit r223113. A proper cleanup of the so_imm
tblgen defintion (made redundant by the mod_imm definition) needs to happen
soon.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223115 91177308-0d34-0410-b5e6-96231b3b80d8
[LICM] Avoind store sinking if no preheader is available

Load instructions are inserted into loop preheaders when sinking stores
and later removed if not used by the SSA updater. Avoid sinking if the
loop has no preheader and avoid crashes. This fixes one more side effect
of not handling indirectbr instructions properly on LoopSimplify.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223119 91177308-0d34-0410-b5e6-96231b3b80d8
Triple: Add AMDHSA operating system type

This operating system type represents the AMD HSA runtime,
and will be required by the R600 backend in order to generate
correct code for this runtime.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223124 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Set the ATC bit on all resource descriptors for the HSA runtime

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223125 91177308-0d34-0410-b5e6-96231b3b80d8
AArch64: make register block rules apply to vector types too.

The blocking code originated in ARM, which is more aggressive about casting
types to a canonical representative before doing anything else, so I missed out
most vector HFAs and broke the ABI. This should fix it.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223126 91177308-0d34-0410-b5e6-96231b3b80d8
fix typo in comment


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223127 91177308-0d34-0410-b5e6-96231b3b80d8
[OCaml] Add Llvm.mdnull.

Patch by Gideon Smeding <gideon.smeding@3ds.com>.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223129 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Set correct number of user sgprs for HSA runtime

We don't support scratch buffers yet with HSA.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223130 91177308-0d34-0410-b5e6-96231b3b80d8
Remove unneccessary code introduced with 223101.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223132 91177308-0d34-0410-b5e6-96231b3b80d8
[MachineCSE] Clear kill-flag on registers imp-def'd by the CSE'd instruction.

Go through implicit defs of CSMI and MI, and clear the kill flags on
their uses in all the instructions between CSMI and MI.
We might have made some of the kill flags redundant, consider:
  subs  ... %NZCV<imp-def>        <- CSMI
  csinc ... %NZCV<imp-use,kill>   <- this kill flag isn't valid anymore
  subs  ... %NZCV<imp-def>        <- MI, to be eliminated
  csinc ... %NZCV<imp-use,kill>
Since we eliminated MI, and reused a register imp-def'd by CSMI
(here %NZCV), that register, if it was killed before MI, should have
that kill flag removed, because it's lifetime was extended.

Also, add an exhaustive testcase for the motivating example.

Reviewed by: Juergen Ributzka <juergen@apple.com>


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223133 91177308-0d34-0410-b5e6-96231b3b80d8
[SwitchLowering] Handle destinations on multiple phi instructions

Follow up from r222926. Also handle multiple destinations from merged
cases on multiple and subsequent phi instructions.

rdar://problem/19106978

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223135 91177308-0d34-0410-b5e6-96231b3b80d8
[Statepoints 3/4] Statepoint infrastructure for garbage collection: SelectionDAGBuilder

This is the third patch in a small series.  It contains the CodeGen support for lowering the gc.statepoint intrinsic sequences (223078) to the STATEPOINT pseudo machine instruction (223085).  The change also includes the set of helper routines and classes for working with gc.statepoints, gc.relocates, and gc.results since the lowering code uses them.  

With this change, gc.statepoints should be functionally complete.  The documentation will follow in the fourth change, and there will likely be some cleanup changes, but interested parties can start experimenting now.

I'm not particularly happy with the amount of code or complexity involved with the lowering step, but at least it's fairly well isolated.  The statepoint lowering code is split into it's own files and anyone not working on the statepoint support itself should be able to ignore it.  

During the lowering process, we currently spill aggressively to stack. This is not entirely ideal (and we have plans to do better), but it's functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics.  Most of the complexity comes from trying to keep relocated copies of values in the same stack slots across statepoints.  Doing so avoids the insertion of pointless load and store instructions to reshuffle the stack.  The current implementation isn't as effective as I'd like, but it is functional and 'good enough' for many common use cases.  

In the long term, I'd like to figure out how to integrate the statepoint lowering with the register allocator.  In principal, we shouldn't need to eagerly spill at all.  The register allocator should do any spilling required and the statepoint should simply record that fact.  Depending on how challenging that turns out to be, we may invest in a smarter global stack slot assignment mechanism as a stop gap measure.  

Reviewed by: atrick, ributzka





git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223137 91177308-0d34-0410-b5e6-96231b3b80d8
Remove '#undef const' from config.h.cmake to sync with autoconf

This define was removed from config.h.in when Rafael removed our use of
libtool.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223138 91177308-0d34-0410-b5e6-96231b3b80d8
cmake: Remove MAXPATHLEN define as autoconf does not provide it

Presumably it was added to the CMake system when MAXPATHLEN was still
used by code built for Windows. Currently only lib/Support/Path.inc uses
MAXPATHLEN, and it should be available on all Unices.

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