This patch introduces following:
* TCI_* and TCD_* macros for incrementation and decrementation
* Fix for invalid use of TCR_8 in one expression

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

llvm-svn: 268826

When running reproducer scripts we need that original symlinks from the
source filesystem are reproduced in the VFS so that different virtual
paths can map to the same file, allowing the FileManager to share the
same UID between these virtual entries. This avoids all sorts of module
redefinition errors when using frameworks.

llvm-svn: 268825

llvm-svn: 268824

Fix the way the ShouldStopHere checker handles the general case of "stepping through line 0 code".  
That's good 'cause it means all the different kinds of source line stepping won't leave user in the middle of
compiler implementation code or code inlined from odd places, etc.  But it turns out that the compiler
also marks functions it MIGHT inline as all being of line 0.  That would mean we single step through this code
instead of just stepping out.  That is both inefficient, and more error prone 'cause these little nuggets tend
to be bits of hand-written assembly and the like and are hard to step through.

This change just checks and if the entire function is marked with line 0, we step out rather than step through.

<rdar://problem/25966460>

llvm-svn: 268823

llvm-svn: 268822

llvm-svn: 268821

Useful when debugging issues within the VFS overlay.

llvm-svn: 268820

Use a StringRef instead of a FileEntry in the moduleMapAddHeader
callback to allow more flexibility on what to collect on further
patches. This changes the interface I introduced in r264971.

llvm-svn: 268819

The value-data line is <PGOFuncName>:<Count_Value>. PGOFuncName might contain
':' for the internal linkage functions. We therefore need to use rsplit,
rather split, to extract the data from the line. This fixes the error when
merging a text profile file to an indexed profile file.

llvm-svn: 268818

object in C. Rather than using the DeclContext (which is very slow because it
triggers us to build a lookup table for the DeclContext), use a separate map
from identifiers to decls for this case, containing only the ones we've
actually deserialized. For convenience, this map is implemented as an
IdentifierResolver.

llvm-svn: 268817

The bitcode upgrade I added for DISubprogram in r266446 was based on the
assumption that the CU node for the subprogram was already materialized by the
time the DISubprogram is visited. This assumption may not hold true as future
versions of LLVM may decide to write out bitcode in a different order. This
patch corrects this by introducing a versioning bit next to the distinct flag to
unambiguously differentiate the new from the old record layouts.

Note for people stabilizing LLVM out-of-tree: This patch introduces a bitcode
incompatibility with llvm trunk revisions from r266446 — this commit. (But
D19987 will ensure that it degrades gracefully).

http://reviews.llvm.org/D20004
rdar://problem/26074194

llvm-svn: 268816

In case of COPY-like instruction we may be able to deduce that a certain
input is unused, based on the used lanes of the register defined by the
instruction.
This even works accross otherwise incompatible copies (no need to have
compatible lanemasks, completely unused operands are still completely
unused). It even makes sense to redo the analysis in this case since we
gained information for a case we previously stopped at because of the
incompatible masks.

llvm-svn: 268815

llvm-svn: 268814

llvm-svn: 268813

llvm-svn: 268812

Added 256-bit vector test as well

llvm-svn: 268811

(this is resubmit of r268529 with minor refactoring. r268529 was reverted
 at r268536 due a memory sanitizer failure.  I have not been able to
 reproduce that failure and I checked all the variable used in my change
 but I could not spot an issue. I did some refactoring and see if it will
 give a clearer hint)

Summary:
Currently, when checking if a stack is "BigStack" or not, it doesn't count into spills and arguments. Therefore, LLVM won't reserve spill slot for this actually "BigStack". This may cause scavenger failure.

Reviewers: rengolin

Subscribers: vitalybuka, aemerson, rengolin, tberghammer, danalbert, srhines, llvm-commits

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

llvm-svn: 268810

Original Commit Message
Extend load/store type canonicalization to handle unordered operations

Extend the type canonicalization logic to work for unordered atomic loads and stores.  Note that while this change itself is fairly simple and low risk, there's a reasonable chance this will expose problems in the backends by suddenly generating IR they wouldn't have seen before.  Anything of this nature will be an existing bug in the backend (you could write an atomic float load), but this will definitely change the frequency with which such cases are encountered.  If you see problems, feel free to revert this change, but please make sure you collect a test case. 

Note that the concern about lowering is now much less likely.  PR27490 proved that we already *were* mucking with the types of ordered atomics and volatiles.  As a result, this change doesn't introduce as much new behavior as originally thought.

llvm-svn: 268809

This reuses the CVTypeDumper from libcodeview to dump full
information about type records within a PDB file.

Differential Revision: http://reviews.llvm.org/D20022
Reviewed By: rnk

llvm-svn: 268808

llvm-svn: 268807

Currently our cmake generates targets like check-llvm-unit and
check-llvm-transforms-loopunroll-x86, but not check-llvm-transforms or
check-llvm-transforms-adce. This is because the search for test suites
only lists the ones with a custom lit.cfg or lit.local.cfg.

Instead, we can do something a little smarter - any directory under
test that isn't called Inputs or inside a directory called Inputs is a
test suite.

llvm-svn: 268806

Fix handleMove() incorrectly extending liveranges when an undef input of
a vreg was moved past the (current) end of the liverange.

llvm-svn: 268805

Again, fairly simple.  Only change is ensuring that we actually copy the property of the load correctly.  The aliasing legality constraints were already handled by the FRE patches.  There's nothing special about unorder atomics from the perspective of the PRE algorithm itself.

llvm-svn: 268804

llvm-svn: 268803

llvm-svn: 268802

llvm-svn: 268801

llvm-svn: 268800

This reverts commit r268796.
I believe it breaks test/CodeGen/X86/asm-mismatched-types.ll with:
Cannot emit physreg copy instruction

llvm-svn: 268799

llvm-svn: 268798

llvm-svn: 268797

ABIs like NaCl uses 32-bit addresses but have 64-bit frame.
The new register class reflects those constraints when choosing a
register class for a address access.

llvm-svn: 268796

This register class may be used by any ABIs that uses x86_64 ISA while
using 32-bit addresses, not just in X32 cases. Make sure the name
reflects that.

llvm-svn: 268795

llvm-svn: 268794

When inferring availability attributes for tvos, watchos from ios, we
use the same source location and set the implicit bit to true.

So when emitting diagnostics on inferred attributes, we have a source
location.

rdar://25893544

llvm-svn: 268793

llvm-svn: 268792

Differential Revision: http://reviews.llvm.org/D19940
Reviewed By: rnk

llvm-svn: 268791

llvm-svn: 268790

part of the error message.

As the caller is the one that needs to add the name of where the "object file"
comes from to the error message as the object file could be in an archive, or
coming from a slice of a Mach-O universal file or a buffer created by a JIT.

In the cases of a Mach-O universal file the architecture name may or may not
also need to be printed which is up to the tool code.  For example if the tool
code is only selecting the host architecture slice then that architecture name
is never printed.

This patch is the change to the libObject code and there will be follow on
commits for changes to the code for each tool.

llvm-svn: 268789

llvm-svn: 268788

Testcase will follow shortly.

llvm-svn: 268787