llvm-svn: 64381

llvm-svn: 64380

llvm-svn: 64379

llvm-svn: 64378

llvm-svn: 64377

llvm-svn: 64376

Turn warning into error. Minor incompatibility with GCC (for scalar types, GCC only produces a warning).

llvm-svn: 64375

It's (currently) not safe to keep certain physical registers live across basic blocks, e.g. x86 fp stack registers.

llvm-svn: 64374

llvm-svn: 64373

If availability info is kept when fallthrough into a bb, add the available registers to live-in set.

llvm-svn: 64372

designating an object.

llvm-svn: 64371

 - Doesn't yet handle case where values are passed in mixed (general
   purpose & floating point) registers; otherwise largely
   functional. Code still needs some cleaning.

Fixes:
MultiSource/Applications/lua/lua
MultiSource/Applications/siod/siod
MultiSource/Applications/sqlite3/sqlite3
SingleSource/Regression/C/PR640
SingleSource/UnitTests/2003-07-09-SignedArgs
SingleSource/UnitTests/2007-03-02-VaCopy

gcc compat test suite results (Darwin x86-32 & -64):
--
# of expected passes		1262
# of unexpected failures	56
# of unresolved testcases	34
# of unsupported tests		2

Compare to: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090209/012050.html

llvm-svn: 64370

Replace one of burr scheduling heuristic with something more sensible. Now calcMaxScratches simply compute the number of true data dependencies. This actually improve a couple of tests in dejagnu suite as many tests in llvm nightly test suite.

llvm-svn: 64369

llvm-svn: 64368

exceptions.

llvm-svn: 64367

llvm-svn: 64366

llvm-svn: 64365

calls with the tail marker when inlining them through an invoke.  Patch,
testcase, and perfect analysis by Jay Foad!

llvm-svn: 64364

llvm-svn: 64363

forget about already inserted expressions.

llvm-svn: 64362

llvm-svn: 64361

Add method 'isSingleton()' to ImmutableSet.  This returns true if the set contains exactly one element.

llvm-svn: 64359

llvm-svn: 64356

llvm-svn: 64355

llvm-svn: 64354

 to use this stat information in the PTH file using a 'StatSysCallCache' object.

Performance impact (Cocoa.h, PTH):
- number of stat calls reduces from 1230 to 425
- fsyntax-only: time improves by 4.2% 

We can reduce the number of stat calls to almost zero by caching negative stat
calls and directory stat calls in the PTH file as well.

llvm-svn: 64353

llvm-svn: 64352

- set the 'StatSysCallCache' object using a setter method instead of
  FileManager's constructor. This allows the cache to be installed after the
  FileManager object is created.
- Add 'file mode' to FileEntry (useful for stat caching)

llvm-svn: 64351

llvm-svn: 64350

similar logic in llvm-gcc and will hopefully be fixed soon.

llvm-svn: 64349

llvm-svn: 64348

llvm-svn: 64347

llvm-svn: 64346

for use by FileManager. FileManager now takes a StatSysCallCache* in its
constructor (which defaults to NULL). This will be used for evaluating whether
or not caching 'stat' system calls in PTH is a performance win. This shim adds
no observable performance impact in the case where the 'StatSysCallCache*' is
null.

llvm-svn: 64345

complex conversions where the conversion between the real types is an
integral promotion. This is how G++ handles complex promotions for its
complex integer extension.

llvm-svn: 64344

system. Since C99 doesn't have overloading and C++ doesn't have
_Complex, there is no specification for    this. Here's what I think
makes sense.

Complex conversions come in several flavors:

  - Complex promotions:  a complex -> complex   conversion where the
    underlying real-type conversion is a floating-point promotion. GCC
    seems to call this a promotion, EDG does something else. This is
    given "promotion" rank for determining the best viable function.
  - Complex conversions: a complex -> complex conversion that is
    not a complex promotion. This is given "conversion" rank for
    determining the best viable   function.
  - Complex-real conversions: a real -> complex or complex -> real
    conversion. This is given "conversion" rank for determining the
    best viable function.

These rules are the same for C99 (when using the "overloadable"
attribute) and C++. However, there is one difference in the handling
of floating-point promotions: in C99, float -> long double and double
-> long double are considered promotions (so we give them "promotion" 
rank), while C++ considers these conversions ("conversion" rank).

llvm-svn: 64343

llvm-svn: 64342

All relevant dejagnu enocding tests pass in this mode.

llvm-svn: 64341

llvm-svn: 64340

Remove a bogus assertion. It's possible a live-in available value is used by a previous instruction.

llvm-svn: 64339