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

llvm-svn: 179170

rather than checking if the source and destination have the same number of
arguments and copying the attributes over directly.

llvm-svn: 179169

Before we would build huge unwrapped lines which take a long time
to optimze.

llvm-svn: 179168

Before:
class A {
public : // test
};

After:
class A {
public: // test
};

Also remove duplicate methods calculating properties of AnnotatedTokens
and make them members of AnnotatedTokens so that they are in a common
place.

llvm-svn: 179167

Depending on the number of bits set in the writemask.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 179166

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 179165

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 179164

We handle these by treating this result of the multiplication as an additional
parameter.

llvm-svn: 179163

Implement suggestions made by Bill Schmidt in post-commit review. Thanks!

llvm-svn: 179162

llvm-svn: 179161

llvm-svn: 179160

Regions that have multiple exit edges are very common. A simple if condition
yields e.g. such a region:

        if
      /   \
  then     else
      \   /
      after

Region: if -> after

This regions contains the bbs 'if', 'then', 'else', but not 'after'. It has
two exit edges 'then' -> 'after' and 'else' -> 'after'.

Previously we scheduled the RegionSimplify pass to translate such regions into
simple regions. With this patch, we now support them natively.

Contributed-by: Star Tan <tanmx_star@yeah.net>
llvm-svn: 179159