llvm-svn: 179224

llvm-svn: 179223

temporarily while we work on plumbing through some changes to continue
supporting gdb on darwin.

This reverts commit r179122.

llvm-svn: 179222

[analyzer] When reporting a leak in RetainCount checker due to an early exit from init, step into init.

The heuristic here (proposed by Jordan) is that, usually, if a leak is due to an early exit from init, the allocation site will be
a call to alloc. Note that in other cases init resets self to [super init], which becomes the allocation site of the object.

llvm-svn: 179221

Compact unwind has an encoding for when we're not able to generate compact
unwind and must generate an EH frame instead. Track that, but still emit that CU
encoding.

llvm-svn: 179220

llvm-svn: 179219

just assembling a file and have passed the option.

llvm-svn: 179218

llvm-svn: 179217

-fstrict-aliasing.
rdar://13622687

llvm-svn: 179216

llvm-svn: 179215

The escaping interaction between Python and grep doesn't work on my
system.  This change fixes the tests for me.

llvm-svn: 179214

This avoids a nasty const correctness issue (AnalysisIDs are const, Pass* isn't).

llvm-svn: 179213

If anyone objects please let me know.

llvm-svn: 179212

In the X86 back end, getMemoryOperandNo() returns the offset
into the operand array of the start of the memory reference descriptor.

Additional code in EncodeInstruction provides an additional adjustment.

This patch places that additional code in a separate function,
called getOperandBias, so that any caller of getMemoryOperandNo
can also call getOperandBias.

llvm-svn: 179211

wasn't always the start of the operand.  If there was a symbol reference, then
Start pointed to that token.  It's very likely there are other places that need
to be updated.

llvm-svn: 179210

to disable following tests for Hexagon that require direct object
generation support.

DebugInfo/dwarf-public-names.ll
DebugInfo/dwarf-version.ll
DebugInfo/member-pointers.ll
DebugInfo/namespace.ll
DebugInfo/two-cus-from-same-file.ll

Fixes bug 15616 - http://llvm.org/bugs/show_bug.cgi?id=15616

llvm-svn: 179209

llvm-svn: 179208

Make the SLP store-merger less paranoid about function calls. We check for function calls when we check if it is safe to sink instructions.

llvm-svn: 179207

llvm-svn: 179206

llvm-svn: 179205

llvm-svn: 179204

I've not seen this happen in practice, and probably can't until we start
allowing decrement-counter-based conditional branches to be double predicated,
but just in case, don't allow predication of a diamond in which both sides have
ctr-defining branches. Even though the branching behavior of these can be
predicated, the counter-decrementing behavior cannot be.

llvm-svn: 179199

version as lea is only available in 64-bit mode.

llvm-svn: 179190

Test cases that regressed due to r179115, plus a few more, were added in
r179182.  Original commit message below:

[ms-inline asm] Use parsePrimaryExpr in lieu of parseExpression if we need to
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]

Part of rdar://13611297

llvm-svn: 179187

21 more little piglits with radeonsi.

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 179186

Mips32 code as Mips16 unless it can't be compiled as Mips 16. For now this
would happen as long as floating point instructions are not needed.
Probably it would also make sense to compile as mips32 if atomic operations
are needed too. There may be other cases too.

A module pass prescans the IR and adds the mips16 or nomips16 attribute
to functions depending on the functions needs.

Mips 16 mode can result in a 40% code compression by utililizing 16 bit
encoding of many instructions.

The hope is for this to replace the traditional gcc way of dealing with
Mips16 code using floating point which involves essentially using soft float
but with a library implemented using mips32 floating point. This gcc 
method also requires creating stubs so that Mips32 code can interact with
these Mips 16 functions that have floating point needs. My conjecture is
that in reality this traditional gcc method would never win over this
new method.

I will be implementing the traditional gcc method also. Some of it is already
done but I needed to do the stubs to finish the work and those required
this mips16/32 mixed mode capability.

I have more ideas for to make this new method much better and I think the old
method will just live in llvm for anyone that needs the backward compatibility
but I don't for what reason that would be needed.

llvm-svn: 179185

symbol with multiple .type declarations.

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

llvm-svn: 179184

llvm-svn: 179183

commit was reverted in r179120, but I do plan on reapplying with a fix shortly.
Part of rdar://13611297

llvm-svn: 179182

llvm-svn: 179181

Patch by Amin Shali.

llvm-svn: 179180

llvm-svn: 179179

Since we only ever instantiate with a type that is a MachOType instantiation,
we don't need to pass template argument.

llvm-svn: 179178

Add a test for time().

llvm-svn: 179177

llvm-svn: 179176

Reviewers: samsonov

Reviewed By: samsonov

CC: samsonov, llvm-commits

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

llvm-svn: 179175

llvm-svn: 179174

Summary:
I did a local comparison between using bash and using lit's runner, and
more of the suite passes with lit than passes with bash.  Most of the
bash failures have to do with /dev/null, which is nonsensical on
Windows, but the lit runner handles it.

The lit shell runner is also much faster than bash, so I would expect
most Windows devs would want it by default.

The behavior can be overridden on any OS by setting
LIT_USE_INTERNAL_SHELL to 0 or 1 in the environment.

Reviewers: chapuni, ddunbar

CC: llvm-commits, timurrrr

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

llvm-svn: 179173

This reverts commit e652085eacbec62e4157d08d3f2f875e6e6d5bb4.

llvm-svn: 179172

These instructions aren't universally available, but depend on a specific
extension to the normal ARM architecture (rather than, say, v6/v7/...) so a new
feature is appropriate.

This also enables the feature by default on A-class cores which usually have
these extensions, to avoid breaking existing code and act as a sensible
default.

llvm-svn: 179171