libc++ implements its' hash objects as deriving from std::unary_function, and the tests test for that. STL @ MS pointed out that the standard doesn't requie these objects to derive from unary_function, and so the tests should not require that either. Change the tests to check for the embedded typedefs - which ARE required. No change to the library.

llvm-svn: 225403

In C++03, a bunch of the arithmetic/logical/comparison functors (such as negate/bit_not.pass/logical_not) were defined as deriving from unary_funtion. That restriction was removed in C++11, but the tests still check for this. Change the test to look for the embedded types first_argument/second_argument/result_type. No change to the library, just more standards-compliant tests. Thanks to STL @ Microsoft for the suggestion.

llvm-svn: 225402

Add API to indicate whether an `MDNode` is distinct.  A distinct node is
not stored in the MDNode uniquing tables, and will never be returned by
`MDNode::get()`.

Although distinct nodes are only currently created by uniquing
collisions (when operands change), PR22111 will allow these nodes to be
explicitly created.

llvm-svn: 225401

E.g. %-foo and %fo-o.

Thanks to eagle-eyed reporter Tomas Brukner.

llvm-svn: 225400

llvm-svn: 225399

Differential Revision: http://reviews.llvm.org/D6797

lldb-gdbserver statically links all llvm dependencies. This allows
dead stripping code and reduces total binary size.

This change modifies lldb-plaform to static link llvm dependencies
like lldb-gdbserver.

llvm-svn: 225398

`MDNode::replaceOperandWith()` changes all instances of metadata.  Stop
using it when linking module flags, since (due to uniquing) the flag
values could be used by other metadata.

Instead, use new API `NamedMDNode::setOperand()` to update the reference
directly.

llvm-svn: 225397

llvm-svn: 225395

llvm-svn: 225394

llvm-svn: 225393

A few loops do trickier things than just iterating on an MVT subset,
so I'll leave them be for now.
Follow-up of r225387.

llvm-svn: 225392

llvm-svn: 225391

This would add another library dependency to Polly. In many cases the
JSCoP interface we have should be enough and an external JSCoP <> OpenSCoP
converter could be written. We can reconsider this if new use cases show up.

llvm-svn: 225390

transform.

Also diagnose typos in the initializer of an invalid C++ declaration.
Both issues were hit using the same line of test code, depending on
whether the code was treated as C or C++.

Fixes PR22092.

llvm-svn: 225389

llvm-svn: 225388

This commit adds a simple iterator over that enum, and a few
functions to create iterator ranges over the most common types.

Differential Revision: http://reviews.llvm.org/D6537

llvm-svn: 225387

This was already fixed by r224481, but apparently was accidentally
reverted in r225207.

llvm-svn: 225386

llvm-svn: 225385

llvm-svn: 225384

options other than just -disassemble so that universal files can be used with other
options combined with -arch options.

No functional change to existing options and use.  One test case added for the
additional functionality with a universal file an a -arch option.

llvm-svn: 225383

Use VGPR_32 register class instead.  These two register classes were
identical and having separate classes was causing
SIInstrInfo::isLegalOperands() to be overly conservative in some cases.

This change is necessary to prevent future paches from missing a folding
opportunity in fneg-fabs.ll.

llvm-svn: 225382

llvm-svn: 225381

llvm-svn: 225380

The two buildbot failures were addressed in LLVM r225378 and CFE r225359.

This rapplies commit 225272 without modifications.

llvm-svn: 225379

llvm-svn: 225378

[Hexagon] Fix 225372 USR register is not fully complete.  Removing Uses = [USR] maintains existing functionality to old instructions without encodings.

llvm-svn: 225377

llvm-svn: 225376

In C++03, a bunch of the arithmetic/logical/comparison functors (such as add/equal_to/logical_or) were defined as deriving from binary_funtion. That restriction was removed in C++11, but the tests still check for this. Change the test to look for the embedded types first_argument/second_argument/result_type. No change to the library, just more standards-compliant tests. Thanks to STL @ Microsoft for the suggestion.

llvm-svn: 225375

llvm-svn: 225374

This is used to simplify the SIFoldOperands pass and make it easier to
fold immediates.

llvm-svn: 225373

llvm-svn: 225372

llvm-svn: 225371

llvm-svn: 225370

This allows folding of sequences like:

s[0:1] = s_mov_b64 4
v_add_i32 v0, s0, v0
v_addc_u32 v1, s1, v1

into

v_add_i32 v0, 4, v0
v_add_i32 v1, 0, v1

llvm-svn: 225369

llvm-svn: 225368

llvm-svn: 225367

llvm-svn: 225366

This change includes the most basic possible GCStrategy for a GC which is using the statepoint lowering code. At the moment, this GCStrategy doesn't really do much - aside from actually generate correct stackmaps that is - but I went ahead and added a few extra correctness checks as proof of concept. It's mostly here to provide documentation on how to do one, and to provide a point for various optimization legality hooks I'd like to add going forward. (For context, see the TODOs in InstCombine around gc.relocate.)

Most of the validation logic added here as proof of concept will soon move in to the Verifier.  That move is dependent on http://reviews.llvm.org/D6811

There was discussion in the review thread about addrspace(1) being reserved for something.  I'm going to follow up on a seperate llvmdev thread.  If needed, I'll update all the code at once.

Note that I am deliberately not making a GCStrategy required to use gc.statepoints with this change. I want to give folks out of tree - including myself - a chance to migrate. In a week or two, I'll make having a GCStrategy be required for gc.statepoints. To this end, I added the gc tag to one of the test cases but not others.

Differential Revision: http://reviews.llvm.org/D6808

llvm-svn: 225365

Shorter and doesn't need -O2 -- but still suboptimal as it's still doing
-emit-obj.  dblaikie says he'll improve this when he'll reland his change
with a fix.

llvm-svn: 225364

r225141 changed the defaults of AllowShortIfStatementsOnASingleLine and
AlignTrailingComments for Google style and added explicit overrides for
Chromium style to undo these changes.  For AllowShortIfStatementsOnASingleLine
that's good as the Android style guide (which Chromium uses for Java) explicitly
permits single-line ifs. But it's silent on trailing comments, to it makes
sense for Chromium style to just follow Google style.

llvm-svn: 225363