Instruction selection priority fixes to remove the XMM/XMMInt/orAVX predicates. Another commit will remove orAVX functions from X86SubTarget.

llvm-svn: 147841

Implement the missing pieces of Evaluate for _Complex types.  With that complete, remove some code from CGExprConstant which is no longer necessary.  While I'm here, a couple minor tweaks to _Complex-in-C++. (Specifically, make _Complex types literal types, and don't warn for _Complex int.)

llvm-svn: 147840

constructors. These are a special case whose behavior cannot be modeled as a
user-written constructor.

llvm-svn: 147839

As we are grubbing through memory chasing down the hierarchy of an ObjC object, protect against the possibility that that object might be just random memory with loops.

llvm-svn: 147838

Per John's comment, it makes sense to ask isLambda on any CXXRecordDecl; make sure that's safe.  Get rid of a check which is now unnecessary in Sema::getFunctionLevelDeclContext().

llvm-svn: 147837

to fix the issues we run into on darwin even though the docs don't
seems to say it will.

llvm-svn: 147835

llvm-svn: 147834

llvm-svn: 147830

when you already know that the address is contained in a bona fide function.  This can be a 
slow call.

llvm-svn: 147829

Also add test cases to the test suite to exercise displaying of variables captured inside a block (Darwin-only).

llvm-svn: 147828

define physical registers. It's currently very restrictive, only catching
cases where the CE is in an immediate (and only) predecessor. But it catches
a surprising large number of cases.

rdar://10660865

llvm-svn: 147827

These heuristics are sufficient for enabling IV chains by
default. Performance analysis has been done for i386, x86_64, and
thumbv7. The optimization is rarely important, but can significantly
speed up certain cases by eliminating spill code within the
loop. Unrolled loops are prime candidates for IV chains. In many
cases, the final code could still be improved with more target
specific optimization following LSR. The goal of this feature is for
LSR to make the best choice of induction variables.

Instruction selection may not completely take advantage of this
feature yet. As a result, there could be cases of slight code size
increase.

Code size can be worse on x86 because it doesn't support postincrement
addressing. In fact, when chains are formed, you may see redundant
address plus stride addition in the addressing mode. GenerateIVChains
tries to compensate for the common cases.

On ARM, code size increase can be mitigated by using postincrement
addressing, but downstream codegen currently misses some opportunities.

llvm-svn: 147826

On Thumb, the displacement computation hardware uses the address of the
current instruction rouned down to a multiple of 4.  Include this
rounding in the UserOffset we compute for each instruction.

When inline asm is present, the instruction alignment may not be known.
Constrain the maximum displacement instead in that case.

This makes it possible for CreateNewWater() and OffsetIsInRange() to
agree about the valid displacements.  When they disagree, infinite
looping happens.

As always, test cases for this stuff are insane.

<rdar://problem/10660175>

llvm-svn: 147825

 - reject definitions of enums within friend declarations
 - require 'enum', not 'enum class', for non-declaring references to scoped
   enumerations

llvm-svn: 147824

llvm-svn: 147823

Add a CFLAGS_EXTRAS make variable to be able to pass things (like '-DTEST_BLOCK_CAPTURED_VARS') to the compile phase.

Plus add a DYLIB_ONLY make variable that can be used to turn off compilation/building of a.out. Example:

[16:39:21] johnny:/Volumes/data/lldb/svn/trunk/test/lang/c/global_variables $ make clean
rm -rf "a.out" "a.out.dSYM"  main.o main.d a.o a.d liba.dylib liba.dylib.dSYM
[16:39:24] johnny:/Volumes/data/lldb/svn/trunk/test/lang/c/global_variables $ make DYLIB_ONLY=YES
clang -gdwarf-2 -O0   -arch x86_64   -c -o a.o a.c
clang -gdwarf-2 -O0   -arch x86_64  a.o -install_name "@executable_path/liba.dylib" -dynamiclib -o "liba.dylib"
[16:39:30] johnny:/Volumes/data/lldb/svn/trunk/test/lang/c/global_variables $

llvm-svn: 147821

llvm-svn: 147820

source file. Otherwise -g -save-temps will error out on the compile
of any .c file.

Fixes about 4000 of the errors in the clang-tests gdb test suite.

llvm-svn: 147819

llvm-svn: 147818

c++ objects with non-trivial assignment/copy functions.
Also, one additional sema check. // rdar://6137845

llvm-svn: 147817

functions that can create file descriptors and close them. It will warn when
there close file descriptor call that returns with EBADF and show the 
corresponding stack backtraces that caused the issue. It will also log all
file descriptor create and delete calls. See the comments at the top of
FDInterposing.cpp for all of the details.

llvm-svn: 147816

in the module when dumping the information in addition to all info that we
were previously showing.

llvm-svn: 147815

the linker driver is found.

llvm-svn: 147814

takes to open and index BSD archives.

llvm-svn: 147813

llvm-svn: 147812

llvm-svn: 147811

[asan] temporary reinstate string.h/strings.h. Removal of those caused a Mac build failulre which I failed to observe before the commit

llvm-svn: 147810

llvm-svn: 147809

intended to cover C++ class definitions.

llvm-svn: 147808

llvm-svn: 147807

The pass is prone to looping, and it is better to crash than loop
forever, even in a -Asserts build.

<rdar://problem/10660175>

llvm-svn: 147806

llvm-svn: 147805

llvm-svn: 147802

After collecting chains, check if any should be materialized. If so,
hide the chained IV users from the LSR solver. LSR will only solve for
the head of the chain. GenerateIVChains will then materialize the
chained IV users by computing the IV relative to its previous value in
the chain.

In theory, chained IV users could be exposed to LSR's solver. This
would be considerably complicated to implement and I'm not aware of a
case where we need it. In practice it's more important to
intelligently prune the search space of nontrivial loops before
running the solver, otherwise the solver is often forced to prune the
most optimal solutions. Hiding the chained users does this well, so
that LSR is more likely to find the best IV for the chain as a whole.

llvm-svn: 147801

llvm-svn: 147799

llvm-svn: 147798

This collects a set of IV uses within the loop whose values can be
computed relative to each other in a sequence. Following checkins will
make use of this information.

llvm-svn: 147797

llvm-svn: 147796

llvm-svn: 147794

llvm-svn: 147793