with a debug build) with this buggy .indirect_symbol directive usage:

% cat test.s
x: .indirect_symbol _y

The assertion is because it is trying to get the symbol index for the
symbol _y when it is writing out the indirect symbol table. This line of
code in MachObjectWriter::WriteObject() :

        Write32(Asm.getSymbolData(*it->Symbol).getIndex());

And while there is a symbol _y it does not have any getSymbolData set which
is only done in MachObjectWriter::BindIndirectSymbols() for pointer sections
or stub sections.  I added a check and an error in there to catch this in case
something slips through.

But to get a better error the parser should detect when a .indirect_symbol
directive is used and it is not in a pointer section or stub section.  To make
that work I moved the handling of the indirect symbol out of the target
independent AsmParser code into the DarwinAsmParser code that can check
for the proper Mach-O section types.

rdar://14825505

llvm-svn: 189497

With the added debug assertions this fix is covered by existing Clang
tests. (& found some other issues, also fixed)

llvm-svn: 189495

Fix a few things in one swoop.

# Add some negative tests.
# Fix some formatting issues.
# Add some missing IsThumb / ARMv8
# Fix some outs / ins mistakes.

llvm-svn: 189490

The usual default of "dmb ish" (inner-shareable) isn't even a valid instruction
on v6M or v7M (well, it does the same thing but software is strongly
discouraged from using it) so we should emit a full-system barrier there.

llvm-svn: 189483

llvm-svn: 189482

Clang is now generating cleaner IR, so this removes the old variants which
should be completely unused.

llvm-svn: 189481

The vqdmlal and vqdmlls instructions are really just a fused pair consisting of
a vqdmull.sN and a vqadd.sN. This adds patterns to LLVM so that we can switch
Clang's CodeGen over to generating these instead of the special vqdmlal
intrinsics.

llvm-svn: 189480

These intrinsics are legalized to V(ALL|ANY)_(NON)?ZERO nodes,
are matched as SN?Z_[BHWDV]_PSEUDO pseudo's, and emitted as
a branch/mov sequence to evaluate to 0 or 1.

Note: The resulting code is sub-optimal since it doesnt seem to be possible
to feed the result of an intrinsic directly into a brcond. At the moment
it uses (SETCC (VALL_ZERO $ws), 0, SETEQ) and similar which unnecessarily
evaluates the boolean twice.

llvm-svn: 189478

llvm-svn: 189476

llvm-svn: 189473

llvm-svn: 189472

llvm-svn: 189471

For now just handles simple comparisons of an ANDed value with zero.
The CC value provides enough information to do any comparison for a
2-bit mask, and some nonzero comparisons with more populated masks,
but that's all future work.

llvm-svn: 189469

The MSA control registers have been added as reserved registers,
and are only used via ISD::Copy(To|From)Reg. The intrinsics are lowered
into these nodes.

llvm-svn: 189468

[mips][msa] Added f[cs]af, f[cs]or, f[cs]ueq, f[cs]ul[et], f[cs]une, fsun, ftrunc_[su], hadd_[su], hsub_[su], sr[al]r, sr[al]ri

llvm-svn: 189467

This uses the infrastructure added for memcpy and memmove in r189331.

llvm-svn: 189458

llvm-svn: 189456

This is breaking numerous Clang tests on the buildbot.

llvm-svn: 189447

The previous default was almost, but not quite enough digits to
represent a floating-point value in a manner which preserves the
representation when it's read back in.  The larger default is much
less confusing.

I spent some time looking into printing exactly the right number of
digits if a precision isn't specified, but it's kind of complicated,
and I'm not really sure I understand what APFloat::toString is supposed
to output for FormatPrecision != 0 (or maybe the current API specification
is just silly, not sure which).  I have a WIP patch if anyone is interested.

llvm-svn: 189442

in use supports it.

llvm-svn: 189439

For now, (defined(X86_64_JIT) && defined(__CYGWIN__)) satisfies Cygwin64.

llvm-svn: 189437

In the LLVM side, x86_64-cygwin is almost as same as x86_64-mingw32.

llvm-svn: 189436

[BumpPtrAllocator] Move DefaultSlabAllocator to a member of BumpPtrAllocator, instead of a static variable.

The problem with having DefaultSlabAllocator being a global static is that it is undefined if BumpPtrAllocator
will be usable during global initialization because it is not guaranteed that DefaultSlabAllocator will be
initialized before BumpPtrAllocator is created and used.

llvm-svn: 189433

Also, fix predicates.

llvm-svn: 189432

No functionality change.

llvm-svn: 189431

llvm-svn: 189430

llvm-svn: 189428

algorithm. Update the split dwarf hashing testcase accordingly - this
should be the last time that the hash of an empty file changes.

llvm-svn: 189427

This reverts r189416.

llvm-svn: 189424

when we can. Migrate from using blocks when we're adding just a
single attribute and floating point values are an unsigned, not signed,
bag of bits.

Update all test cases accordingly.

llvm-svn: 189419

Link.exe's command line options are case-insensitive. This patch
adds a new attribute to OptTable to let the option parser to compare
options, ignoring case.

Command lines are generally case-insensitive on Windows. CL.exe is an
exception. So this new attribute should be useful for other commands
running on Windows.

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

llvm-svn: 189416

createClassType, createStructType, createUnionType, createEnumerationType,
and createForwardDecl will take an optional StringRef to pass in
the unique identifier.

llvm-svn: 189410

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

llvm-svn: 189408

Summary: MASM let's you do stuff like 'MOV FS:20, EAX' and 'MOV EAX, FS:20'

Reviewers: craig.topper, rnk

Reviewed By: rnk

CC: llvm-commits

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

llvm-svn: 189407

first. Use this to turn the PPC modifiers into PPC specific expressions,
allowing them to work on constants.

llvm-svn: 189400

llvm-svn: 189396

This patch merges LoopVectorize of InnerLoopVectorizer and InnerLoopUnroller by adding checks for VF=1. This helps in erasing the Unroller code that is almost identical to the InnerLoopVectorizer code.

llvm-svn: 189391

llvm-svn: 189388

llvm-svn: 189349

We want to convert code like (or (srl N, 8), (shl N, 8)) into (srl (bswap N),
const), but this is only valid if the bits above 16 on the source pattern are
0, the checks we were doing on this were slightly wrong before.

llvm-svn: 189348