No functionality change.

llvm-svn: 197310

CompilationDatabase.cpp:stripPositionalArgs(): Match not "no-integrated-as" but "-no-integrated-as", it really fixes r197229.

llvm-svn: 197309

These were just missing an expected-no-diagnostics directive.

Also add -std=c++11 to a test warning noisly about extensions.

llvm-svn: 197308

Symbol names exported from a DLL should be undecorated, not prefixed by
an underscore ones.

llvm-svn: 197307

llvm-svn: 197306

is specialized by an explicit specialization, start from the first declaration
in case we've got a member of a class template (redeclarations might not number
the template parameters the same way).

Our recover here is still far from ideal.

llvm-svn: 197305

[block-freq] Rename getEntryFrequency() -> getEntryFreq() to match getBlockFreq() in all *BlockFrequencyInfo*.

llvm-svn: 197304

[block-freq] Teach branch probability how to return the edge weight in between a BasicBlock and one of its successors.

IMHO At some point BasicBlock should be refactored along the lines of
MachineBasicBlock so that successors/weights are actually embedded within the
block. Now is not that time though.

llvm-svn: 197303

llvm-svn: 197302

and still inherit the designated initializers of its super class.

llvm-svn: 197301

change SBQueue to have a shared pointer to its corresponding
QueueImpl object for binary compatibility.
<rdar://problem/15657926> 

llvm-svn: 197300

This patch was submitted to the list for review and didn't receive a LGTM.

(In fact one explicit objection and one query were raised.)

This reverts commit r197295.

llvm-svn: 197299

class templates (a Microsoft extension).

llvm-svn: 197298

llvm-svn: 197297

[block-freq] Refactor LiveInterals::getSpillWeight to use the new MachineBlockFrequencyInfo methods.

This is slightly more interesting than the previous batch of changes.
Specifically:

1. We refactor getSpillWeight to take a MachineBlockFrequencyInfo (MBFI)
object. This enables us to completely encapsulate the actual manner we
use the MachineBlockFrequencyInfo to get our spill weights. This yields
cleaner code since one does not need to fetch the actual block frequency
before getting the spill weight if all one wants it the spill weight. It
also gives us access to entry frequency which we need for our
computation.

2. Instead of having getSpillWeight take a MachineBasicBlock (as one
might think) to look up the block frequency via the MBFI object, we
instead take in a MachineInstr object. The reason for this is that the
method is supposed to return the spill weight for an instruction
according to the comments around the function.

llvm-svn: 197296

Differential Revision: http://llvm-reviews.chandlerc.com/D2392

llvm-svn: 197295

clang still doesn't emit the right llvm code when initializing multi-D arrays it seems.

For e.g. the following code would still crash for me on Windows 7, 64 bit:

auto f4 = new int[100][200][300]{{{1,2,3}, {4, 5, 6}}, {{10, 20, 30}}};

It seems that the final new loop that iterates through each outermost array and memsets it to zero gets confused with its final ptr arithmetic.

This patch ensures that it converts the pointer to the allocated type (int [200][300]) before incrementing it (instead of using the base type: 'int').

Richard somewhat squeamishly approved the patch (as a quick fix to potentially make it into 3.4) - while exhorting for a more optimized fix in the future. http://llvm-reviews.chandlerc.com/D2398
 
Thanks Richard!

llvm-svn: 197294

Use CHECK-LABEL, add an i64 version, check store instructions.

llvm-svn: 197293

llvm-svn: 197292

[block-freq] Store MBFI as a field on SpillPlacement so we can access it to get the entry frequency while processing data.

llvm-svn: 197291

[block-freq] Update MachineBlockPlacement and RegAllocGreedy to use the new MachineBlockFrequencyInfo methods.

llvm-svn: 197290

llvm-svn: 197289

llvm-svn: 197288

[block-freq] Add the equivalent methods to MachineBlockFrequencyInfo and BlockFrequencyInfo that were added to BlockFrequencyImpl in r197285 and r197284.

llvm-svn: 197287

llvm-svn: 197286

[block-freq] Add a print method on BlockFrequencyImpl for printing block frequencies and a convenience method for the common case of getting/printing a basic block.

BlockFrequencies can only be printed relative to their entry frequency. Thus
since the entry frequency is no longer necessarily a static constant on the
BlockFrequency class and is instead a potentially dynamic value taken from
BlockFrequencyImpl, we must necessarily print it via a method on
BlockFrequencyImpl.

llvm-svn: 197285

This is a property associated with a function, not with BlockFrequency data.
Additionally it loosens the artifical requirement that the entry frequency
arbitrarily be the same for every function.

There is a series of patches forthcoming updating various code that uses the old
way of getting a block frequency to the new location.

llvm-svn: 197284

Also update for the current naming style.

llvm-svn: 197283

were falling into the cases for 24-bit branch kinds which are not 24-bit
branches.  The routine is to return false for fixups are expected to always
be resolvable at assembly time. Which these three fixups are as they have
limited displacement and are for local references within a function.

rdar://15586725

llvm-svn: 197282

llvm-svn: 197281

llvm-svn: 197280

llvm-svn: 197279

llvm-svn: 197278

Remove APInt::extractBit since it is already implemented via operator[]. Change tests for extractBit to test operator[].

llvm-svn: 197277

llvm-svn: 197276

DebugInfo: Move type units into the debug_types section with appropriate comdat grouping and type unit headers

This commit does not complete the type units feature - there are issues
around fission support (skeletal type units, pubtypes/pubnames) and
hashing of some types including those containing references to types in
other type units.

Originally committed as r197073 and reverted in r197079.
Recommitted as r197197 to reproduce the failure and reverted as r197199

Turns out there was unstable ordering in the type unit dumping code.
Fixed by using MapVector in DWARFContext to store the debug_types
comdat sections.

Recommitted as r197210 with a fix to dumping and reverted as r197211
because I was a bit gun shy and thought I saw a failure that turned out
to be unrelated.

So here we go - once more with feeling! \o/

llvm-svn: 197275

llvm-svn: 197274

There's nothing special about type traits accepting two arguments.

This commit eliminates BinaryTypeTraitExpr and switches all related handling
over to TypeTraitExpr.

Also fixes a CodeGen failure with variadic type traits appearing in a
non-constant expression.

The BTT/TT prefix and evaluation code is retained as-is for now but will soon
be further cleaned up.

This is part of the ongoing work to unify type traits.

llvm-svn: 197273

llvm-svn: 197272

llvm-svn: 197271