that mainline needs no autoupgrade logic for intrinsics yet, woohoo!

llvm-svn: 145178

I'll work on turning this into something intelligible tomorrow.

llvm-svn: 145177

autoupgrade logic for 2.9 and before.

llvm-svn: 145176

trampoline forms.  Both of these were correct in LLVM 3.0, and we don't
need to support LLVM 2.9 and earlier in mainline.

llvm-svn: 145174

llvm-svn: 145173

remove asmparsing and documentation support for "volatile load", which was only produced by LLVM 2.9 and earlier.  LLVM 3.0 and later prefers "load volatile".

llvm-svn: 145172

Upgrade syntax of tests using volatile instructions to use 'load volatile' instead of 'volatile load', which is archaic.

llvm-svn: 145171

llvm-svn: 145170

I think this is the last of autoupgrade that can be removed in 3.1.
Can the atomic upgrade stuff also go?

llvm-svn: 145169

llvm-svn: 145168

llvm-svn: 145167

LLVM 3.0 and later.

llvm-svn: 145165

llvm-svn: 145164

llvm-svn: 145163

Besides cleaning up the repetition in the installhdrs target, the point of this
change is to provide a separate do-installhdrs target that can be used directly
from clang's runtime/libcxx makefile to install a copy of the headers along
with clang.  <rdar://problem/10397739>

llvm-svn: 145162

These instructions are not generated by the backend yet, this will come in a later commit.

llvm-svn: 145161

Removing that buildbot would be a better solution, but this is at least
a temporary workaround.

llvm-svn: 145160

Fix a couple of 80-column violations.

llvm-svn: 145159

pass. This is designed to achieve one of the important optimizations
that the old code placement pass did, but more simply.

This is a somewhat rough and *very* conservative version of the
transform. We could get a lot fancier here if there are profitable cases
to do so. In particular, this only looks for a single pattern, it
insists that the loop backedge being rotated away is the last backedge
in the chain, and it doesn't provide any means of doing better in-loop
placement due to the rotation. However, it appears that it will handle
the important loops I am finding in the LLVM test suite.

llvm-svn: 145158

llvm-svn: 145157

llvm-svn: 145154

Merge 128-bit and 256-bit X86ISD node types for VPERMILPS and VPERMILPD. Simplify some shuffle lowering code since V1 can never be UNDEF due to canonalizing that occurs when shuffle nodes are created.

llvm-svn: 145153

llvm-svn: 145152

and on clang, which seams to handled "=b" correctly even when ebx is the
PIC register.

llvm-svn: 145149

Collapse X86ISD node types for PUNPCKH*, PUNPCKL*, UNPCKLP*, and UNPCKHP* to not be type specific. Now we just have integer high and low and floating point high and low. Pattern matching will choose the correct instruction based on the vector type.

llvm-svn: 145148

llvm-svn: 145147

llvm-svn: 145146

llvm-svn: 145145

llvm-svn: 145144

for adding other tests.

llvm-svn: 145143

and linux.

llvm-svn: 145142

was returning incorrect values in rare cases, and incorrectly marking
exact conversions as inexact in some more common cases. Fixes PR11406, and a
missed optimization in test/CodeGen/X86/fp-stack-O0.ll.

llvm-svn: 145141

llvm-svn: 145138

I don't see how the project is using LLVM and we really can't list every user of
the clang analyzer. Sorry.

llvm-svn: 145137

llvm-svn: 145136

llvm-svn: 145135

llvm-svn: 145134

tablegen patterns for scalar FMA4 operations and intrinsic. Also
add tests for vfmaddsd.

Patch by Jan Sjodin

llvm-svn: 145133

llvm-svn: 145129

In Microsoft mode, make "Unqualified lookup into dependent bases of class templates" works  inside a friend function definition at class scope.

Basically we have to look into the parent *lexical* DeclContext for friend functions at class scope. That's because calling GetParent() return the namespace or file DeclContext.

This fixes all remaining cases of "Unqualified lookup into dependent bases of class templates" when parsing MFC code with clang.

llvm-svn: 145127