Merging r213894:
------------------------------------------------------------------------
r213894 | hans | 2014-07-24 14:09:45 -0700 (Thu, 24 Jul 2014) | 4 lines

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/branches/release_35@214248 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r213815:
------------------------------------------------------------------------
r213815 | mren | 2014-07-23 16:13:23 -0700 (Wed, 23 Jul 2014) | 17 lines

SimplifyCFG: fix a bug in switch to table conversion

We use gep to access the global array "switch.table", and the table index
should be treated as unsigned. When the highest bit is 1, this commit
zero-extends the index to an integer type with larger size.

For a switch on i2, we used to generate:
%switch.tableidx = sub i2 %0, -2
getelementptr inbounds [4 x i64]* @switch.table, i32 0, i2 %switch.tableidx

It is incorrect when %switch.tableidx is 2 or 3. The fix is to generate
%switch.tableidx = sub i2 %0, -2
%switch.tableidx.zext = zext i2 %switch.tableidx to i3
getelementptr inbounds [4 x i64]* @switch.table, i32 0, i3 %switch.tableidx.zext

rdar://17735071

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214251 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r213880:
------------------------------------------------------------------------
r213880 | mren | 2014-07-24 10:18:33 -0700 (Thu, 24 Jul 2014) | 1 line

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/branches/release_35@214252 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r213884:
------------------------------------------------------------------------
r213884 | mren | 2014-07-24 10:57:09 -0700 (Thu, 24 Jul 2014) | 1 line

Try to fix the bots again by moving test to X86 directory.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214253 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r213895:
------------------------------------------------------------------------
r213895 | mren | 2014-07-24 14:13:20 -0700 (Thu, 24 Jul 2014) | 2 lines

Feedback from Hans on r213815. No functionaility change.

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214254 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r214129:
------------------------------------------------------------------------
r214129 | echristo | 2014-07-28 15:00:44 -0700 (Mon, 28 Jul 2014) | 2 lines

Regenerate autoconf, previous updates to the configury haven't
been updating configure.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214261 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r214287:
------------------------------------------------------------------------
r214287 | chandlerc | 2014-07-29 22:44:04 -0700 (Tue, 29 Jul 2014) | 9 lines

Don't manually (and forcibly) run the verifier on the entire module from
the jump instruction table pass. First, the verifier is already built
into all the tools. The test case is adapted to just run llvm-as
demonstrating that we still catch the broken module. Second, the
verifier is *extremely* slow. This was responsible for very significant
compile time regressions.

If you have deployed a Clang binary anywhere from r210280 to this
commit, you really want to re-deploy.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214288 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r214180:
------------------------------------------------------------------------
r214180 | sstankovic | 2014-07-29 15:39:24 +0100 (Tue, 29 Jul 2014) | 5 lines

[mips] Don't use odd-numbered single precision registers for fastcc calling
convention if -mno-odd-spreg is used.

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

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214304 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r213773:
------------------------------------------------------------------------
r213773 | jholewinski | 2014-07-23 13:40:45 -0400 (Wed, 23 Jul 2014) | 5 lines

[NVPTX] Make sure we do not generate MULWIDE ISD nodes when optimizations are disabled

With optimizations disabled, we disable the isel patterns for mul.wide; but we
were still generating MULWIDE ISD nodes.  Now, we only try to generate MULWIDE
ISD nodes in DAGCombine if the optimization level is not zero.
------------------------------------------------------------------------



git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214309 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r213793:
------------------------------------------------------------------------
r213793 | jholewinski | 2014-07-23 16:23:47 -0400 (Wed, 23 Jul 2014) | 4 lines

[NVPTX] Silence a GCC warning found by the buildbots

The cast to NVPTXTargetLowering was missing a 'const', but let's
just access the right pointer through the subtarget anyway.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214310 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r214331:
------------------------------------------------------------------------
r214331 | arphaman | 2014-07-30 13:30:11 -0700 (Wed, 30 Jul 2014) | 4 lines

docs: update the command guide documentation for llvm-profdata.

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

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214353 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r213798:
------------------------------------------------------------------------
r213798 | grosbach | 2014-07-23 13:41:31 -0700 (Wed, 23 Jul 2014) | 7 lines

DAG: fp->int conversion for non-splat constants.

Constant fold the lanes of the input constant build_vector individually
so we correctly handle when the vector elements are not all the same
constant value.

PR20394
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214413 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r214519:
------------------------------------------------------------------------
r214519 | rafael | 2014-08-01 07:57:05 -0700 (Fri, 01 Aug 2014) | 3 lines

Remove lto_codegen_set_attr.

It was never exported, so no functionality change.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214682 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r214429:
------------------------------------------------------------------------
r214429 | willschm | 2014-07-31 12:50:53 -0700 (Thu, 31 Jul 2014) | 29 lines

Disable IsSub subregister assert.  pr18663.

This is a follow-up to the activity in the bug at
http://llvm.org/bugs/show_bug.cgi?id=18663 .  The underlying issue has
to do with how the KILL pseudo-instruction is handled.  I defer to
Hal/Jakob/Uli for additional details and background.

This will disable the (bad?) assert, add an associated fixme comment,
and add a pair of tests.

The code change and the pr18663-2.ll test are copied from the referenced
bug.  That test does not immediately fail in my environment, but I have
added the pr18663.ll test which does.

(Comment from Hal)
to provide everyone else with some context, this assert was not bad when
it was written. At that time, we only generated KILL pseudo instructions
around subregister copies. This logic, unfortunately, had its own problems.
In r199797, the relevant logic in MachineCopyPropagation was replaced to
generate KILLs for other kinds of copies too. This change in semantics broke
this now-problematic assumption in AggressiveAntiDepBreaker. The
AggressiveAntiDepBreaker really needs a proper cleanup to deal with the
change, but removing the assert (which just allows the function to return
false) is a safe conservative behavior, and should do for the time being.





------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214683 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r214423:
------------------------------------------------------------------------
r214423 | hfinkel | 2014-07-31 12:13:38 -0700 (Thu, 31 Jul 2014) | 9 lines

Fix ScalarEvolutionExpander when creating a PHI in a block with duplicate predecessors

It seems that when I fixed this, almost exactly a year ago, I did not quite do
it correctly. When we have duplicate block predecessors, we can indeed not have
different incoming values for the same block, but we *must* have duplicate
entries. So, instead of skipping the duplicates, we explicitly add the
duplicate incoming values.

Fixes PR20442.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214684 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r213899:
------------------------------------------------------------------------
r213899 | joerg | 2014-07-24 15:20:10 -0700 (Thu, 24 Jul 2014) | 2 lines

Don't use 128bit functions on PPC32.

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214685 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r213883:
------------------------------------------------------------------------
r213883 | compnerd | 2014-07-24 10:46:36 -0700 (Thu, 24 Jul 2014) | 5 lines

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/branches/release_35@214686 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r213896:
------------------------------------------------------------------------
r213896 | compnerd | 2014-07-24 15:09:06 -0700 (Thu, 24 Jul 2014) | 6 lines

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/branches/release_35@214687 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r213726:
------------------------------------------------------------------------
r213726 | nicholas | 2014-07-22 23:24:49 -0700 (Tue, 22 Jul 2014) | 2 lines

We may visit a call that uses an alloca multiple times in callUsesLocalStack, sometimes with IsNocapture true and sometimes with IsNocapture false. We accidentally skipped work we needed to do in the IsNocapture=false case if we were called with IsNocapture=true the first time. Fixes PR20405!

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214688 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r213665:
------------------------------------------------------------------------
r213665 | tnorthover | 2014-07-22 08:47:09 -0700 (Tue, 22 Jul 2014) | 11 lines

X86: drop relocations on __eh_frame sections globally.

Without this, we produce non-extern relocations when targeting older OS X
versions that ld64 can't cope with in the particular context of __eh_frame
sections (who'd want generic relocation-processing anyway?).

This means that an updated linker (ld64 from Xcode 3.2.6 or later) may be
needed when targeting such platforms with a modern version of LLVM, but this is
probably the case anyway and a reasonable requirement.

PR20212, rdar://problem/17544795
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_35@214689 91177308-0d34-0410-b5e6-96231b3b80d8