llvm-svn: 151274

Rename it to LiveRegs to make it more clear what's stored inside.

llvm-svn: 151273

Assuming that a single std::set node adds 3 control words, a bitvector
can store (3*8+4)*8=224 registers in the allocated memory of a single
element in the std::set (x86_64). Also we don't have to call malloc
for every register added.

llvm-svn: 151269

rdar://10873652

As part of this I updated the llvm-mc disassembler C API to always call the
SymbolLookUp call back even if there is no getOpInfo call back.  If there is a
getOpInfo call back that is tried first and then if that gets no information
then the  SymbolLookUp is called.  I also made the code more robust by
memset(3)'ing to zero the LLVMOpInfo1 struct before then setting
SymbolicOp.Value before for the call to getOpInfo.  And also don't use any
values from the  LLVMOpInfo1 struct if getOpInfo returns 0.  And also don't
use any of the ReferenceType or ReferenceName values from SymbolLookUp if it
returns NULL. rdar://10873563 and rdar://10873683

For the X86 target also fixed bugs so the annotations get printed. 

Also fixed a few places in the ARM target that was not producing symbolic
operands for some instructions.  rdar://10878166

llvm-svn: 151267

Also, some basic clean up.  Patch by Evandro Menezes.

llvm-svn: 151266

Before register allocation, instructions can be moved across calls in
order to reduce register pressure.  After register allocation, we don't
gain a lot by moving callee-saved defs across calls.  In fact, since the
scheduler doesn't have a good idea how registers are used in the callee,
it can't really make good scheduling decisions.

This changes the schedule in two ways: 1. Latencies to call uses and
defs are no longer accounted for, causing some random shuffling around
calls.  This isn't really a problem since those uses and defs are
inaccurate proxies for what happens inside the callee.  They don't
represent registers used by the call instruction itself.

2. Instructions are no longer moved across calls.  This didn't happen
very often, and the scheduling decision was made on dubious information
anyway.

As with any scheduling change, benchmark numbers shift around a bit,
but there is no positive or negative trend from this change.

This makes the post-ra scheduler 5% faster for ARM targets.

The secret motivation for this patch is the introduction of register
mask operands representing call clobbers.  The most efficient way of
handling regmasks in ScheduleDAGInstrs is to model them as barriers for
physreg live ranges, but not for virtreg live ranges.  That's fine
pre-ra, but post-ra it would have the same effect as this patch.

llvm-svn: 151265

llvm-svn: 151262

llvm-svn: 151252

llvm-svn: 151251

of instantiated C++ templates.

Patch by Kristof Beyls!

llvm-svn: 151250

llvm-svn: 151249

llvm-svn: 151248

it with memcpy. This also fixes a problem on big-endian hosts, where
addUnaligned would return different results depending on the alignment
of the data.

llvm-svn: 151247

returns 'true' and emits a warning.  Help it out.

llvm-svn: 151242

llvm-svn: 151238

llvm-svn: 151235

llvm-svn: 151234

Ignore undef uses completely.
Use a more explicit SlotIndex API.
Add more explicit comments.

llvm-svn: 151233

of x are zero. This optimizes rev + lsr 16 to rev16.

rdar://10750814

llvm-svn: 151230

Added array subscript to SparseSet for convenience.
Slight reorg to make it easier to manage the def/use sets.

llvm-svn: 151228

llvm-svn: 151226

value is zero. Instead of a cmov + op, issue an conditional op instead. e.g.
    cmp   r9, r4
    mov   r4, #0
    moveq r4, #1 
    orr   lr, lr, r4

should be:
    cmp   r9, r4
    orreq lr, lr, #1

That is, optimize (or x, (cmov 0, y, cond)) to (or.cond x, y). Similarly extend
this to xor as well as (and x, (cmov -1, y, cond)) => (and.cond x, y).

It's possible to extend this to ADD and SUB but I don't think they are common.

rdar://8659097

llvm-svn: 151224

llvm-svn: 151223

The bulk masking operations from register mask operands don't account
for reserved registers.

llvm-svn: 151222

llvm-svn: 151213

llvm-svn: 151211

llvm-svn: 151210

llvm-svn: 151205

The standard function epilog includes a .size directive, but ppc64 uses
an alternate local symbol to tag the actual start of each function.

Until recently, binutils accepted the .size directive as:
 .size	test1, .Ltmp0-test1
however, using this directive with recent binutils will result in the error:
 .size expression for XXX does not evaluate to a constant
so we must use the label which actually tags the start of the function.

llvm-svn: 151200

Patch by Joe Groff!

llvm-svn: 151183

llvm-svn: 151178

llvm-svn: 151169

llvm-svn: 151167

llvm-svn: 151166

Add some data structures to represent for loops.  These will be
referenced during object processing to do any needed iteration and
instantiation.

Add foreach keyword support to the lexer.

Add a mode to indicate that we're parsing a foreach loop.  This allows
the value parser to early-out when processing the foreach value list.

Add a routine to parse foreach iteration declarations.  This is
separate from ParseDeclaration because the type of the named value
(the iterator) doesn't match the type of the initializer value (the
value list).  It also needs to add two values to the foreach record:
the iterator and the value list.

Add parsing support for foreach.

Add the code to process foreach loops and create defs based
on iterator values.

Allow foreach loops to be matched at the top level.

When parsing an IDValue check if it is a foreach loop iterator for one
of the active loops.  If so, return a VarInit for it.

Add Emacs keyword support for foreach.

Add VIM keyword support for foreach.

Add tests to check foreach operation.

Add TableGen documentation for foreach.

Support foreach with multiple objects.

Support non-braced foreach body with one object.

Do not require types for the foreach declaration.  Assume the iterator
type from the iteration list element type.

llvm-svn: 151164

llvm-svn: 151160

chip in r139383, and the PSP components of the triple are really
annoying to parse. Let's leave this chapter behind. There is no reason
to expect LLVM to see a PSP-related triple these days, and so no
reasonable motivation to support them.

It might be reasonable to prune a few of the older MIPS triple forms in
general, but as those at least cause no burden on parsing (they aren't
both a chip and an OS!), I'm happy to leave them in for now.

llvm-svn: 151156

Worth another 45k (1%) off of a large C++ testcase.

rdar://10909458

llvm-svn: 151144

llvm-svn: 151143

llvm-svn: 151142