Deals with a dwarf2 -> dwarf3 DW_FORM_ref_addr change.

llvm-svn: 179122

llvm-svn: 179121

llvm-svn: 179120

columns is essentially impossible to edit.

llvm-svn: 179119

and mips16 on a per function basis.

Because this patch is somewhat involved I have provide an overview of the
key pieces of it.

The patch is written so as to not change the behavior of the non mixed
mode. We have tested this a lot but it is something new to switch subtargets
so we don't want any chance of regression in the mainline compiler until
we have more confidence in this.

Mips32/64 are very different from Mip16 as is the case of ARM vs Thumb1.
For that reason there are derived versions of the register info, frame info, 
instruction info and instruction selection classes.

Now we register three separate passes for instruction selection.
One which is used to switch subtargets (MipsModuleISelDAGToDAG.cpp) and then
one for each of the current subtargets (Mips16ISelDAGToDAG.cpp and
MipsSEISelDAGToDAG.cpp).

When the ModuleISel pass runs, it determines if there is a need to switch
subtargets and if so, the owning pointers in MipsTargetMachine are
appropriately changed.

When 16Isel or SEIsel is run, they will return immediately without doing
any work if the current subtarget mode does not apply to them.

In addition, MipsAsmPrinter needs to be reset on a function basis.

The pass BasicTargetTransformInfo is substituted with a null pass since the
pass is immutable and really needs to be a function pass for it to be
used with changing subtargets. This will be fixed in a follow on patch.

llvm-svn: 179118

This commit adds the infrastructure for performing bottom-up SLP vectorization (and other optimizations) on parallel computations.
The infrastructure has three potential users:

  1. The loop vectorizer needs to be able to vectorize AOS data structures such as (sum += A[i] + A[i+1]).

  2. The BB-vectorizer needs this infrastructure for bottom-up SLP vectorization, because bottom-up vectorization is faster to compute.

  3. A loop-roller needs to be able to analyze consecutive chains and roll them into a loop, in order to reduce code size. A loop roller does not need to create vector instructions, and this infrastructure separates the chain analysis from the vectorization.

This patch also includes a simple (100 LOC) bottom up SLP vectorizer that uses the infrastructure, and can vectorize this code:

void SAXPY(int *x, int *y, int a, int i) {
  x[i]   = a * x[i]   + y[i];
  x[i+1] = a * x[i+1] + y[i+1];
  x[i+2] = a * x[i+2] + y[i+2];
  x[i+3] = a * x[i+3] + y[i+3];
}

llvm-svn: 179117

llvm-svn: 179116

parse an identifier.  Otherwise, parseExpression may parse multiple tokens,
which makes it impossible to properly compute an immediate displacement.
An example of such a case is the source operand (i.e., [Symbol + ImmDisp]) in
the below example:

 __asm mov eax, [Symbol + ImmDisp]

The existing test cases exercise this patch.
rdar://13611297

llvm-svn: 179115

therefore not at all) of the pc or statement list. We also don't
need to emit the compilation dir so save so space and time
and don't bother.

Fix up the testcase accordingly and verify that we don't emit
the attributes or the items that they use.

llvm-svn: 179114

Some general cleanup and only scan the end of a BB for branches (once we're
done with the terminators and debug values, then there should not be any other
branches). These address post-commit review suggestions by Bill Schmidt.

No functionality change intended.

llvm-svn: 179112

llvm-svn: 179111

llvm-svn: 179110

rather than deriving the StringRef from the Start and End SMLocs.

Using the Start and End SMLocs works fine for operands such as [Symbol], but
not for operands such as [Symbol + ImmDisp].  All existing test cases that
reference a variable exercise this patch.
rdar://13602265

llvm-svn: 179109

when result type of protocol property and getter method
differ by fixing a more serious problem. When a forward
protocol declaration comes between its definition and
its use in class protocol list, the forward protocol
ast was being used in building the protocol list.
// rdar://12522752

llvm-svn: 179108

Before:
switch (...) {
  // a
  // b
// c
case first:
  break;
}

After:
switch (...) {
// a
// b
// c
case first:
  break;
}

llvm-svn: 179107

This pattern occurs in SROA output due to the way vector arguments are lowered
on ARM.

The testcase from PR15525 now compiles into this, which is better than the code
we got with the old scalarrepl:
_Store:
	ldr.w	r9, [sp]
	vmov	d17, r3, r9
	vmov	d16, r1, r2
	vst1.8	{d16, d17}, [r0]
	bx	lr

Differential Revision: http://llvm-reviews.chandlerc.com/D647

llvm-svn: 179106

On PowerPC, non-vector loads and stores have r+i forms; however, in functions
with large stack frames these were not being used to access slots far from the
stack pointer because such slots were out of range for the signed 16-bit
immediate offset field. This increases register pressure because we need a
separate register for each offset (when the r+r form is used). By enabling
virtual base registers, we can deal with large stack frames without unduly
increasing register pressure.

llvm-svn: 179105

llvm-svn: 179104

This happens whenever there is a c-style explicit cast to nullptr not
surrounded by parentheses following a return statement.

- Added a white space before nullptr if the character before is alphanumeric
  when replacing the null pointer expression.
- Simplified visitor
- Addes tests

llvm-svn: 179103

Some translations here are not 1x1 because there are grep|grep
chains that are non-trivial to implement in terms of FileCheck features. I
made an effort for the tests to remain as similar as possible; do let me know
if you notice anything fishy. The good news are that some buggy tests were
fixed (grep | not grep - a bug waiting to happen).

llvm-svn: 179102

Summary:
Some codebases use these kinds of macros in functions, e.g. Chromium's
IPC_BEGIN_MESSAGE_MAP, IPC_BEGIN_MESSAGE_HANDLER, etc.

Reviewers: djasper, klimek

Reviewed By: klimek

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D645

llvm-svn: 179099

This adds an emacs editor integration (thanks to Ami Fischman). Also
pulls out the style into a variable for the vi integration and just
uses clang-formats defaults style in clang-format-diff.py.

llvm-svn: 179098

For now it is templated only on being 64 or 32 bits. I will add little/big
endian next.

llvm-svn: 179097

llvm-svn: 179096

DWARF parser: Fix DWARF-2/3 incompatibility: size of DW_FORM_ref_addr is the same as DW_FORM_addr in DWARF2, and is 4/8 bytes on 32/64-bit DWARF starting from DWARF3. Adding a test for this is a huge pain - generating and uploading pre-built binary with DWARF3 debug info is way too ugly, and writing fine-grained unittests for DebugInfo is impossible, as it doesn't expose any headers in include/llvm. That said, I'm going to choose the second approach and submit the patch exposing DebugInfo headers for review soon enough.

llvm-svn: 179095

llvm-svn: 179094

Credit goes to Timur Iskhodzhanov for finding the problem and solution.

llvm-svn: 179093

One more follow-up to r179082 - parse PIC/PIE arguments even on platfroms that force default PIC (like Darwin x86-64), otherwise specifying -fPIC will produce bogus unused argument warning

llvm-svn: 179092

llvm-svn: 179091

[Sanitizer] fix TSan tests: remove global ctor from sanitizer_common, run load_shared_lib test only in lit

llvm-svn: 179090

llvm-svn: 179089

llvm-svn: 179088

llvm-svn: 179087

llvm-svn: 179086

llvm-svn: 179085

llvm-svn: 179084

The save area is twice as big and there is no struct return slot. The
stack pointer is always 16-byte aligned (after adding the bias).

Also eliminate the stack adjustment instructions around calls when the
function has a reserved stack frame.

llvm-svn: 179083

Differential Revision: http://llvm-reviews.chandlerc.com/D502

llvm-svn: 179082

Previously, the analyzer used isIntegerType() everywhere, which uses the C
definition of "integer". The C++ predicate with the same behavior is
isIntegerOrUnscopedEnumerationType().

However, the analyzer is /really/ using this to ask if it's some sort of
"integrally representable" type, i.e. it should include C++11 scoped
enumerations as well. hasIntegerRepresentation() sounds like the right
predicate, but that includes vectors, which the analyzer represents by its
elements.

This commit audits all uses of isIntegerType() and replaces them with the
general isIntegerOrEnumerationType(), except in some specific cases where
it makes sense to exclude scoped enumerations, or any enumerations. These
cases now use isIntegerOrUnscopedEnumerationType() and getAs<BuiltinType>()
plus BuiltinType::isInteger().

isIntegerType() is hereby banned in the analyzer - lib/StaticAnalysis and
include/clang/StaticAnalysis. :-)

Fixes real assertion failures. PR15703 / <rdar://problem/12350701>

llvm-svn: 179081

expression, look through pseudo-object expressions.

rdar://13602832

llvm-svn: 179080