llvm-svn: 158287

llvm-svn: 158286

expressions.

llvm-svn: 158285

llvm-svn: 158284

The PPC64 backend had patterns for i32 <-> i64 extensions and truncations that
would leave self-moves in the final assembly. Replacing those patterns with ones
based on the SUBREG builtins yields better-looking code.

Thanks to Jakob and Owen for their suggestions in this matter.

llvm-svn: 158283

llvm-svn: 158282

llvm-svn: 158281

Revert pair constructors back to using is_convertible instead of is_constructible.  This should pull things into alignment with the final draft.  Fixes http://llvm.org/bugs/show_bug.cgi?id=13063#add_comment.

llvm-svn: 158280

Use XOP vpcom intrinsics in patterns instead of a target specific SDNode type. Remove the custom lowering code that selected the SDNode type.

llvm-svn: 158279

llvm-svn: 158278

llvm-svn: 158277

llvm-svn: 158276

llvm-svn: 158275

Disabling a spurious deprecation warning about using PathV1 from within the PathV1 implementation file.

llvm-svn: 158274

llvm-svn: 158273

No functionality change.

llvm-svn: 158272

llvm-svn: 158270

llvm-svn: 158265

correlated, and thinks that cmpOp2 may be used uninitialized.

llvm-svn: 158263

[Sanitizer] Use __libc_malloc/__libc_free instead of malloc/free inside internal allocator on Linux (important for TSan)

llvm-svn: 158261

llvm-svn: 158260

Tail merging had been disabled on PPC because it would disturb bundling decisions
made during pre-RA scheduling on the 970 cores. Now, however, all bundling decisions
are made during post-RA scheduling, and tail merging is generally beneficial (the
average test-suite speedup is insignificantly positive).

Largest test-suite speedups:
MultiSource/Benchmarks/mediabench/gsm/toast/toast - 30%
MultiSource/Benchmarks/BitBench/uuencode/uuencode - 23%
SingleSource/Benchmarks/Shootout-C++/ary - 21%
SingleSource/Benchmarks/Stanford/Queens - 17%

Largest slowdowns:
MultiSource/Benchmarks/MiBench/security-sha/security-sha - 24%
MultiSource/Benchmarks/McCat/03-testtrie/testtrie - 22%
MultiSource/Applications/JM/ldecod/ldecod - 14%
MultiSource/Benchmarks/mediabench/g721/g721encode/encode - 9%

This is improved by using full (instead of just critical) anti-dependency breaking,
but doing so still causes miscompiles and so cannot yet be enabled by default.

llvm-svn: 158259

in the same line do not override getting a cursor for the previous declaration.

e.g:

int x, y;
@synthesize prop1, prop2;

pointing at 'x'/'prop1' would give 'y'/'prop2' because their source ranges overlap.

rdar://11361113

llvm-svn: 158258

llvm-svn: 158256

The LiveRegMatrix represents the live range of assigned virtual
registers in a Live interval union per register unit. This is not
fundamentally different from the interference tracking in RegAllocBase
that both RABasic and RAGreedy use.

The important differences are:

- LiveRegMatrix tracks interference per register unit instead of per
  physical register. This makes interference checks cheaper and
  assignments slightly more expensive. For example, the ARM D7 reigster
  has 24 aliases, so we would check 24 physregs before assigning to one.
  With unit-based interference, we check 2 units before assigning to 2
  units.

- LiveRegMatrix caches regmask interference checks. That is currently
  duplicated functionality in RABasic and RAGreedy.

- LiveRegMatrix is a pass which makes it possible to insert
  target-dependent passes between register allocation and rewriting.
  Such passes could tweak the register assignments with interference
  checking support from LiveRegMatrix.

Eventually, RABasic and RAGreedy will be switched to LiveRegMatrix.

llvm-svn: 158255

llvm-svn: 158254

Still not linked in; comments and additions are very welcome.

llvm-svn: 158253

llvm-svn: 158250

This deduplicates some code from the optimizing register allocators, and
it means that it is now possible to change the register allocators'
solutions simply by editing the VirtRegMap between the register
allocator pass and the rewriter.

llvm-svn: 158249

llvm-svn: 158248

I can't imagine why these were added. Trial and error.

llvm-svn: 158247

llvm-svn: 158246

While this code is valid C++98, it is not valid C++11. The problem can be
reduced to:

class MDNode;

class DIType {
  operator MDNode*() const {return 0;}
};

class WeakVH {
  WeakVH(MDNode*) {}
};

int main() {
  DIType di;
  std::pair<void*, WeakVH> p(std::make_pair((void*)0, di)));
}

This was not detected by any of the bots we have because they either compile
C++98 with libstdc++ (which allows it), or C++11 with libc++ (which incorrectly
allows it). I ran into the problem when compiling with VS 2012 RC.

Thanks to Richard for explaining the issue.

llvm-svn: 158245

OK, not really. We don't want to reintroduce the old rewriter hacks.

This patch extracts virtual register rewriting as a separate pass that
runs after the register allocator. This is possible now that
CodeGen/Passes.cpp can configure the full optimizing register allocator
pipeline.

The rewriter pass uses register assignments in VirtRegMap to rewrite
virtual registers to physical registers, and it inserts kill flags based
on live intervals.

These finalization steps are the same for the optimizing register
allocators: RABasic, RAGreedy, and PBQP.

llvm-svn: 158244

to a change done long ago in r57393.

llvm-svn: 158243

The fast register allocator is not supposed to work in the optimizing
pipeline. It doesn't make sense to compute live intervals, run full copy
coalescing, and then run RAFast.

Fast register allocation in the optimizing pipeline is better done by
RABasic.

llvm-svn: 158242

llvm-svn: 158241

than being given the pthread_mutex_t from the Mutex and locks that.  That allows us to
track ownership of the Mutex better.  

Used this to switch the LLDB_CONFIGURATION_DEBUG enabled assert when we can't get the
gdb-remote sequence mutex to assert when the thread that had the mutex releases it.  This
is generally more useful information than saying just who failed to get it (since the
code that had it locked often had released it by the time the assert fired.)

llvm-svn: 158240

This could happen for cases like this:

- (NSArray *)getAllNames:(NSArray *)images {
  NSMutableArray *results = [NSMutableArray array];
  for (auto img in images) {
    [results addObject:img.name];
  }
  return results;
}

Here the property access will fail because 'img' has type 'id', rather than,
say, NSImage.

This warning will not fire in templated code, since the 'id' could have
come from a template parameter.

llvm-svn: 158239

llvm-svn: 158238