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

TableGen had been generating a different name for an anonymous multiclass's
NAME for every def in the multiclass. This had an unfortunate side effect: it
was impossible to reference one def within the multiclass from another (in the
parameter list, for example). By making sure we only generate an anonymous name
once per multiclass (which, as it turns out, requires only changing the name
parameter to reference type), we can now concatenate NAME within the multiclass
with a def name in order to generate a reference to that def.

This does not matter so much, in and of itself, but is necessary for a
follow-up commit that will fix variable capturing in implicit anonymous
multiclass defs (and that is important).

llvm-svn: 198340

llvm-svn: 198339

When widening an IV to remove s/zext, we generally try to eliminate
the original narrow IV. However, LCSSA phi nodes outside the loop were
still using the original IV. Clean this up more aggressively to avoid
redundancy in generated code.

llvm-svn: 198338

Add basic emulation mapping for NetBSD/amd64, so that clang -m32 works
as expected.

llvm-svn: 198337

llvm-svn: 198336

llvm-svn: 198335

Based on a patch by Maciej Piechotka.

llvm-svn: 198334

This reverts r197927 until the discussion on llvm-commits comes to a
conclusion.

llvm-svn: 198333

llvm-svn: 198332

Make sure clang-tblgen, clang++, and clang-cl get created in the Clang
binary build directory.

llvm-svn: 198331

llvm-svn: 198330

In a standalone build, Clang binaries should end up in Clang's build folder,
not LLVM's.

Xcode still has a few issues finding auxiliary tools and libraries in the
build folders. I'll fix those next.

llvm-svn: 198328

Mark PUSHFS64/PUSHGS64/POPFS64/POPGS64 as In64BitMode and remove the hack from the disassembler table builder.

llvm-svn: 198327

llvm-svn: 198326

llvm-svn: 198325

Mark all x86 Int_ and _Int patterns as isCodeGenOnly so the disassembler table builder doesn't need to string match them to exclude them.

llvm-svn: 198323

property accessor's missing backing ivar. This eliminates
the bogus warning being issued. // rdar://15728901

llvm-svn: 198322

llvm-svn: 198321

The separate Xcode project generated for Clang is putting the clang
executables into the same location where the LLVM executables are
going. This is wrong, and breaks the Clang build because we try to
create clang++ and clang-cl symlinks in the wrong place and to the
wrong place.

As a stop-gap to get these builds working again, teach the symlink
generation to point into the LLVM executable directory instead.

llvm-svn: 198319

When building Clang separately from LLVM with CMake, one should set
the path of llvm-config via the cache variable LLVM_CONFIG.

llvm-svn: 198316

llvm-svn: 198313

llvm-svn: 198312

PIC code.

llvm-svn: 198311

Summary: Added CommentPragmas option for this.

Reviewers: djasper, klimek

Reviewed By: klimek

CC: cfe-commits, klimek

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

llvm-svn: 198310

The backend string is only verified when available as it's possible to run
clang IRGen for targets that haven't been built or don't exist in LLVM.

llvm-svn: 198309