llvm-svn: 198387

llvm-svn: 198386

Apologies for the noise - we're seeing some Go failures with cgo
interacting with Clang's debug info due to this change.

llvm-svn: 198385

llvm-svn: 198384

llvm-svn: 198382

Summary:
No functionality change.

This code should live here long-term because we should be able to use it
to compute correct vftable names.

It turns out that the most natural way to implement the naming algorithm
is to use a caching layer similar to what we already have for virtual
table info in VTableContext.  Subsequent changes will take advantage of
this to fix PR17748, where we have a vbtable name collision.

Reviewers: majnemer

CC: cfe-commits

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

llvm-svn: 198380

llvm-svn: 198379

This functionality was enabled by r198374. Here's a test to ensure it
works and we don't regress it.

Based on a patch by Maciej Piechotka.

llvm-svn: 198377

This ModulePass schedules the set of Polly canonicalization passes. It is a
debugging tool that can be used to preoptimize .ll files for Polly processing.

llvm-svn: 198376

Removed an unnecessary %select from the alignas diagnostics. The attribute already knows how it was spelled.

llvm-svn: 198375

It was never specialized so let's just remove that unused
configurability and always do the default.

llvm-svn: 198374

This diagnostic should not have had the manual quotation marks. Its only usage passed in an Attr object, which was already quoted when printing the diagnostic. However, there was no test case that caught this bug -- one has been added.

llvm-svn: 198373

Removing some more unnecessary manual quotes from attribute diagnostics. Updated the associated testcase because QualType pretty printing was an improvement.

llvm-svn: 198372

llvm-svn: 198371

Also the code makes the impression this was happening, shouldEnablePolly()
always returns false for optlevel equal to zero. This was previously different,
but was accidentally changed by a commit a couple of months ago. As this
behavior was mainly a debugging tool and adding this to clang never really made
sense, we just remove the last traces.

llvm-svn: 198370

The greedy register allocator tries to split a live-range around each
instruction where it is used or defined to relax the constraints on the entire
live-range (this is a last chance split before falling back to spill).
The goal is to have a big live-range that is unconstrained (i.e., that can use
the largest legal register class) and several small local live-range that carry
the constraints implied by each instruction.
E.g.,
Let csti be the constraints on operation i.

V1=
op1 V1(cst1)
op2 V1(cst2)

V1 live-range is constrained on the intersection of cst1 and cst2.

tryInstructionSplit relaxes those constraints by aggressively splitting each
def/use point:
V1=
V2 = V1
V3 = V2
op1 V3(cst1)
V4 = V2
op2 V4(cst2)

Because of how the coalescer infrastructure works, each new variable (V3, V4)
that is alive at the same time as V1 (or its copy, here V2) interfere with V1.
Thus, we end up with an uncoalescable copy for each split point.

To make tryInstructionSplit less aggressive, we check if the split point
actually relaxes the constraints on the whole live-range. If it does not, we do
not insert it.
Indeed, it will not help the global allocation problem:
- V1 will have the same constraints.
- V1 will have the same interference + possibly the newly added split variable
  VS.
- VS will produce an uncoalesceable copy if alive at the same time as V1.

<rdar://problem/15570057>

llvm-svn: 198369

Reworded the NSObject attribute diagnostics to be more consistent with other attribute diagnostics. Also updated the associated test case.

llvm-svn: 198368

backing ivar by not issuing this warning if ivar is referenced
somewhere and accessor makes method calls. // rdar://15727325

llvm-svn: 198367

Removing some manual quotes from this diagnostic, since the AST diagnostics engine knows how to handle NamedDecl objects.

llvm-svn: 198365

This fixes a crash that appeared when generating dotty graphs for functions
without loops (for which we do not calculate polyhedral information).

llvm-svn: 198364

llvm-svn: 198362

obvious.

llvm-svn: 198361

CR logicals (crand, crxor, etc.) on the P7 need to be in the first slot of each
dispatch group. The old itinerary entry was just wrong (but has not mattered
because we don't generate these instructions).

This will matter when, in an upcoming commit, we start generating these
instructions.

llvm-svn: 198359

llvm-svn: 198358

llvm-svn: 198357

Several of the 64-bit fixed-point instructions with immediate operands were
using the 32-bit (i32) operand nodes instead of the corresponding 64-bit (i64)
operand definitions (u16imm instead of u16imm64, for example).

This error has had no effect so far, but would have caused type-checking
violations with an upcoming change.

llvm-svn: 198356

Updated the wording of two attribute-related diagnostics so that they print the offending attribute name. Also updates the associated test cases.

llvm-svn: 198355

As noted in the comment above CodeGenPrepare::OptimizeInst, which aggressively
sinks compares to reduce pressure on the condition register(s), for targets
such as PowerPC with multiple condition registers, this may not be the right
thing to do. This adds an HasMultipleConditionRegisters boolean to TLI, and
CodeGenPrepare::OptimizeInst is skipped when HasMultipleConditionRegisters is
true.

This functionality will be used by the PowerPC backend in an upcoming commit.
Especially when the PowerPC backend starts tracking individual condition
register bits as separate allocatable entities (which will happen in this
upcoming commit), this sinking from CodeGenPrepare::OptimizeInst is
significantly suboptimial.

llvm-svn: 198354

llvm-svn: 198353

I originally had these using opt -verify, and I never removed the
-verify when converting them to use llvm-as instead, so these were
failing because of using the -verify argument which llvm-as doesn't have
instead of what it's actually supposed to be testing.

llvm-svn: 198352

Use an if statement instead of a pair of ternary operators checking
the same condition.
Use a cheap method call rather than returning the local symbol.

llvm-svn: 198351

llvm-svn: 198350

llvm-svn: 198349

Even within a multiclass, we had been generating concrete implicit anonymous
defs when parsing values (generally in value lists). This behavior was
incorrect, and led to errors when multiclass parameters were used in the
parameter list of the implicit anonymous def.

If we had some multiclass:

multiclass mc<string n> {

 ... : SomeClass<SomeOtherClass<n> >

The capture of the multiclass parameter 'n' would not work correctly, and
depending on how the implicit SomeOtherClass was used, either TableGen would
ignore something it shouldn't, or would crash.

To fix this problem, when inside a multiclass, we generate prototype anonymous
defs for implicit anonymous defs (just as we do for explicit anonymous defs).
Within the multiclass, the current record prototype is populated with a node
that is essentially: !cast<SomeOtherClass>(!strconcat(NAME, anon_value_name)).
This is then resolved to the correct concrete anonymous def, in the usual way,
when NAME is resolved during multiclass instantiation.

llvm-svn: 198348

A ValueType in a pattern dag is a type cast, and GetNumNodeResults should
handle it (the type cast has only one result).

This comes up, for example, during the type checking of pattern fragments, for
example, AArch64's Neon_combine_2d fragment is:
  dag Operands = (ops node:$Rm, node:$Rn);
  dag Fragment = (v2f64 (concat_vectors (v1f64 node:$Rm), (v1f64 node:$Rn)));

llvm-svn: 198347

llvm-svn: 198346

llvm-svn: 198345

Plugins need to go in build/Debug/lib as well (rather than build/lib/Debug).

Also, fix the SHLIBDIR path for Xcode, which by default includes Xcode build
settings rather than a simple %(build_mode)s parameter.

llvm-svn: 198344

Fixes <rdar://problem/15713945>.

llvm-svn: 198343

for pointing this out.
 

llvm-svn: 198341