When a large live range is evicted, it will usually be split when it comes
around again. By deferring evicted live ranges, the splitting happens at a time
when the interference pattern is more realistic. This prevents repeated
splitting and evictions.

llvm-svn: 126282

exist. Cheat and do this by adding some wrappers around the PresumedLoc
machinery that directly return the line and column number.

llvm-svn: 126281

llvm-svn: 126280

Fix PR9276: We were missing the checks for auto deducing to different types in the same declaration group in the template instantiation case.

llvm-svn: 126279

of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up
doing was:
- Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics
  the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple 
  to give us the machine type from llvm::Triple::ArchType.
- There is a new ArchSpec::Core definition which further qualifies the CPU
  core we are dealing with into a single enumeration. If you need support for
  a new Core and want to debug it in LLDB, it must be added to this list. In
  the future we can allow for dynamic core registration, but for now it is
  hard coded.
- The ArchSpec can now be initialized with a llvm::Triple or with a C string
  that represents the triple (it can just be an arch still like "i386").
- The ArchSpec can still initialize itself with a architecture type -- mach-o
  with cpu type and subtype, or ELF with e_machine + e_flags -- and this will
  then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core.
  The mach-o cpu type and subtype can be accessed using the getter functions:
  
  uint32_t
  ArchSpec::GetMachOCPUType () const;

  uint32_t
  ArchSpec::GetMachOCPUSubType () const;
  
  But these functions are just converting out internal llvm::Triple::ArchSpec 
  + ArchSpec::Core back into mach-o. Same goes for ELF.

All code has been updated to deal with the changes.

This should abstract us until later when the llvm::TargetSpec stuff gets
finalized and we can then adopt it.

llvm-svn: 126278

llvm-svn: 126277

Use interval sizes instead of spill weights to determine if it is legal to evict
interference. A smaller interval can evict interference if all interfering live
ranges are larger.

Allow multiple interferences to be evicted as along as they are all larger than
the live range being allocated.

Spill weights are still used to select the preferred eviction candidate.

llvm-svn: 126276

	NilArgChecker
	CFNumberCreateChecker
	ClassReleaseChecker

llvm-svn: 126275

It would run PostObjCMessage checkers even for PreObjCMessage checking.

llvm-svn: 126274

llvm-svn: 126273

-In general, don't have the BugReporter deleting BugTypes, BugTypes will eventually become owned by checkers
 and outlive the BugReporter. In the meantime, there will be some leaks since some checkers assume that
 the BugTypes they create will be destroyed by the BugReporter.
-Have BugReporter::EmitBasicReport create BugTypes that are reused if the same name & category strings
 are passed to EmitBasicReport. These BugTypes are owned and destroyed by the BugReporter.
 This allows bugs reported through EmitBasicReport to be coalesced.
-Remove the llvm::FoldingSet<BugReportEquivClass> from BugType and move it into the BugReporter.
 For uniquing BugReportEquivClass also use the BugType* so that we can iterate over all of them using only one set.

llvm-svn: 126272

llvm-svn: 126271

llvm-svn: 126270

errornously defined inside an objc class. 
// rdar://7029784

llvm-svn: 126269

llvm-svn: 126268

llvm-svn: 126267

mostly just shuffles various possibilities for recovery into a more
straightforward order, but also unifies a couple of diagnostics.

llvm-svn: 126266

Plus add missing break stmts for "case" blocks.

llvm-svn: 126265

[AVX] General VUNPCKL codegen support.

llvm-svn: 126264

Fix Builder::execute() to more properly pass the desired environment
to tools.

llvm-svn: 126263

FunctionProtoTypeLoc with NULL function parameter types, which can
occur in invalid code. Fixes PR9247 / <rdar://problem/9037911>.

llvm-svn: 126262

specifier in legacy code. Patch is reviewed offline by Doug.
// rdar://9036633.

llvm-svn: 126261

llvm-svn: 126260

This is based on the observation that long live ranges are more difficult to
allocate, so there is a better chance of solving the puzzle by handling the big
pieces first. The allocator will evict and split long alive ranges when they get
in the way.

RABasic is still using spill weights for its priority queue, so the interface to
the queue has been virtualized.

llvm-svn: 126259

llvm-svn: 126258

llvm-svn: 126257

  template <class T1, class T2> pair<T1,T2> make_pair(const T1&, const T2&);
to
  template <class T1, class T2> pair<V1, V2> make_pair(T1&&, T2&&);
so explicitly specifying the template arguments to make_pair<> is going to break
when C++0x rolls through. Replace them with equivalent std::pair<>. Patch by
James Dennett!

llvm-svn: 126256

invocation function into the debug info.  Rather than faking up a class,
which is tricky because of the custom layout we do, we just emit a struct
directly from the layout information we've already got.

Also, don't emit an unnecessarily parameter alloca for this "variable".

llvm-svn: 126255

the stack.

llvm-svn: 126254

values from all of the loop's exiting blocks are equal. Patch by Andrew Clinton.

llvm-svn: 126253

block and, eventually, C++ lambda) contexts.

llvm-svn: 126252

Fixed a hang in the expression parser's result synthesizer that occurs when the function generated for the expression is completely empty except for a NULL_STMT.  This happens sometimes when the parser returns errors.

llvm-svn: 126251

We need a longer long when testing this pathe Microsoft fixed-underlying-type extension for enumeration types

llvm-svn: 126250

Use them within EmulateInstructionARM.cpp to save repetitive typing.

llvm-svn: 126247

llvm-svn: 126246

Patch by Csaba Raduly!

llvm-svn: 126245

llvm-svn: 126244

  enum X : long { Value = 0x100000000 };

when in Microsoft-extension mode (-fms-extensions). This (now C++0x)
feature has been supported since Microsoft Visual Studio .NET 2003.

llvm-svn: 126243

llvm-svn: 126240

llvm-svn: 126238