a new toy hazard recognizier heuristic which attempts to direct the
scheduler to avoid clumping large groups of loads or stores too densely.

llvm-svn: 62291

Sema::ActOnFunctionDeclarator().  
No functionality change.  

llvm-svn: 62290

llvm-svn: 62289

llvm-svn: 62288

llvm-svn: 62287

Validate dbg_* intrinsics before lowering them.

llvm-svn: 62286

llvm-svn: 62285

to support MachineInstr-based scheduling in addition to
SDNode-based scheduling.

llvm-svn: 62284

loops, hoisting instructions all the way out in one step rather
than hoisting them one nest level at a time. Also, make a few
other code simplifications. This speeds up MachineLICM
by several fold.

llvm-svn: 62283

llvm-svn: 62282

llvm-svn: 62281

llvm-svn: 62279

init of static vars still not working. I'll get back to it tomorrow or so

llvm-svn: 62278

llvm-svn: 62277

llvm-svn: 62276

and into the ScheduleDAGInstrs class, so that they don't get
destructed and re-constructed for each block. This fixes a
compile-time hot spot in the post-pass scheduler.

To help facilitate this, tidy and do some minor reorganization
in the scheduler constructor functions.

llvm-svn: 62275

enum E {
 A = 1U,
 B
};

Don't make an implicit cast expr of null for B.

llvm-svn: 62274

- IdentifierInfo can now (optionally) have its string data not be
  co-located with itself.  This is for use with PTH.  This aspect is a
  little gross, as getName() and getLength() now make assumptions
  about a possible alternate representation of IdentifierInfo.
  Perhaps we should make IdentifierInfo have virtual methods?

IdentifierTable:
- Added class "IdentifierInfoLookup" that can be used by
  IdentifierTable to perform "string -> IdentifierInfo" lookups using
  an auxilliary data structure.  This is used by PTH.
- Perform tests show that IdentifierTable::get() does not slow down
  because of the extra check for the IdentiferInfoLookup object (the
  regular StringMap lookup does enough work to mitigate the impact of
  an extra null pointer check).
- The upshot is that now that some IdentifierInfo objects might be
  owned by the IdentiferInfoLookup object.  This should be reviewed.

PTH:
- Modified PTHManager::GetIdentifierInfo to *not* insert entries in
  IdentifierTable's string map, and instead create IdentifierInfo
  objects on the fly when mapping from persistent IDs to
  IdentifierInfos.  This saves a ton of work with string copies,
  hashing, and StringMap lookup and resizing.  This change was
  motivated because when processing source files in the PTH cache we
  don't need to do any string -> IdentifierInfo lookups.
- PTHManager now subclasses IdentifierInfoLookup, allowing clients of
  IdentifierTable to transparently use IdentifierInfo objects managed
  by the PTH file.  PTHManager resolves "string -> IdentifierInfo"
  queries by doing a binary search over a sorted table of identifier
  strings in the PTH file (the exact algorithm we use can be changed
  as needed).

These changes lead to the following performance changes when using PTH on Cocoa.h:
- fsyntax-only: 10% performance improvement
- Eonly: 30% performance improvement

llvm-svn: 62273

llvm-svn: 62272

this fixes PR3332

llvm-svn: 62271

and uninitialized use options.

llvm-svn: 62270

Use light weight DebugInfo object directly.

llvm-svn: 62269

llvm-svn: 62268

llvm-svn: 62267

previous commit.

llvm-svn: 62266

llvm-svn: 62265

llvm-svn: 62264

- Looking at the number of sign bits of the a sext instruction to determine  whether new trunc + sext pair should be added when its source is being evaluated in a different type.

llvm-svn: 62263

llvm-svn: 62262

llvm-svn: 62261

llvm-svn: 62260

llvm-svn: 62259

the ADDRspii addressing mode.

llvm-svn: 62258

changes in the last commit.

llvm-svn: 62257

llvm-svn: 62256

llvm-svn: 62255

  sequences in SPUDAGToDAGISel.cpp and SPU64InstrInfo.td, killing custom
  DAG node types as needed.
- i64 mul is now a legal instruction, but emits an instruction sequence
  that stretches tblgen and the imagination, as well as violating laws of
  several small countries and most southern US states (just kidding, but
  looking at a function with 80+ parameters is really weird and just plain
  wrong.)
- Update tests as needed.

llvm-svn: 62254

 - Mostly written as an entertaining exercise in enumerating large or
   (countably, naturally) infinite sets. But hey, its useful too!

 - Idea is to number all C-types so that the N-th type can quickly be
   computed, with a good deal of flexibility about what types to
   include, and taking some care so that the (N+1)-th type is
   interestingly different from the N-th type. For example, using the
   default generator, the 1,000,000-th function type is:
--
typedef _Complex int T0;
typedef char T1 __attribute__ ((vector_size (4)));
typedef int T2 __attribute__ ((vector_size (4)));
T2 fn1000000(T0 arg0, signed long long arg1, T1 arg2, T0 arg3);
--
   and the 1,000,001-th type is:
--
typedef _Complex char T0;
typedef _Complex char T2;
typedef struct T1 { T2 field0; T2 field1; T2 field2; } T1;
typedef struct T3 {  } T3;
unsigned short fn1000001(T0 arg0, T1 arg1, T3 arg2);
--

   Computing the 10^1600-th type takes a little less than 1s. :)

llvm-svn: 62253

llvm-svn: 62251

llvm-svn: 62250