llvm-svn: 190779

Summary:
When a git repository had multiple remotes, ${repository} will be set to a multiline string. This causes compilation errors in SVNVersion.inc.

Fix this by limiting the output of utils/GetRepositoryPath to the first remote (which is reasonably likely to be 'origin').

Reviewers: jordan_rose

CC: llvm-commits, t.p.northover

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

llvm-svn: 190778

The port originally had special patterns for extload, mapping them to the
same instructions as sextload.  It seemed neater to have patterns that
match "an extension that is allowed to be signed" and "an extension that
is allowed to be unsigned".

This was originally meant to be a clean-up, but it does improve the handling
of promoted integers a little, as shown by args-06.ll.

llvm-svn: 190777

llvm-svn: 190776

llvm-svn: 190775

llvm-svn: 190774

Previous discussion:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063909.html

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

llvm-svn: 190773

llvm-svn: 190772

This is a re-commit of r190764, with an extra check to make sure that we're not
performing the transformation on illegal types (a small test case has been
added for this as well).

Original commit message:

The PPC backend uses a target-specific DAG combine to turn unaligned Altivec
loads into a permutation-based sequence when possible. Unfortunately, the
target-specific DAG combine is not always called on all loads of interest
(sometimes the routines in DAGCombine call CombineTo such that the new node and
users are not added to the worklist); allowing the combine to trigger early
(before type legalization) mitigates this problem. Because the autovectorizers
only create legal vector types, I don't expect a lot of cases where this
optimization is enabled by type legalization in practice.

llvm-svn: 190771

llvm-svn: 190770

llvm-svn: 190769

Summary:
The '?' flag uses the last section group if the last had a section
group.  We treat combining an explicit section group and the '?' as a
hard error.

This fixes PR17198.

Reviewers: rafael, bkramer

Reviewed By: bkramer

CC: llvm-commits

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

llvm-svn: 190768

For alignment purposes, the instruction array will always have an even
number of entries, with the final entry potentially unused (in which
case the array will be one longer than indicated by the count of unwind
codes field).

Reviewed by Anton Korobeynikov, Charles Davis and Nico Rieck.

llvm-svn: 190767

 data structures.

The Win64 EH data structures must be of type IMAGE_REL_AMD64_ADDR32NB
instead of IMAGE_REL_AMD64_ADDR32. This is easiely achieved by adding
the VK_COFF_IMGREL32 modifier to the symbol reference.
Change also references to start and end of the SEH range of a function
as offsets to start of the function.

Reviewed by Jim Grosbach, Charles Davis and Nico Rieck.

llvm-svn: 190766

This is causing test-suite failures.

Original commit message:

The PPC backend uses a target-specific DAG combine to turn unaligned Altivec
loads into a permutation-based sequence when possible. Unfortunately, the
target-specific DAG combine is not always called on all loads of interest
(sometimes the routines in DAGCombine call CombineTo such that the new node and
users are not added to the worklist); allowing the combine to trigger early
(before type legalization) mitigates this problem. Because the autovectorizers
only create legal vector types, I don't expect a lot of cases where this
optimization is enabled by type legalization in practice.

llvm-svn: 190765

The PPC backend uses a target-specific DAG combine to turn unaligned Altivec
loads into a permutation-based sequence when possible. Unfortunately, the
target-specific DAG combine is not always called on all loads of interest
(sometimes the routines in DAGCombine call CombineTo such that the new node and
users are not added to the worklist); allowing the combine to trigger early
(before type legalization) mitigates this problem. Because the autovectorizers
only create legal vector types, I don't expect a lot of cases where this
optimization is enabled by type legalization in practice.

llvm-svn: 190764

DAGCombiner::isAlias can be called with SrcValue1 or SrcValue2 null, and we
can't use AA in this case (if we try, then the casting code in AA will assert).

llvm-svn: 190763

so it can be better used for general interoperability testing between mips32
and mips16.

llvm-svn: 190762

llvm-svn: 190759

llvm-svn: 190758

Will clean up header files and m_register_infos shortly.

llvm-svn: 190757

Marshall Clow:  LWG Issue 2056: future_errc enums start with value 0 (invalid value for broken_promise).

llvm-svn: 190756

Unlike C++11's "thread_local" keyword, C11's "_Thread_local" is in the
reserved namespace, meaning we provide it unconditionally; it is marked
as KEYALL in TokenKinds.def.

This means that like all the other C11 keywords, we can expose its
presence through __has_extension().

llvm-svn: 190755

Also assembly/disassembly tests, and for sha256rnds2, aliases with an explicit
xmm0 dependency.

llvm-svn: 190754

llvm-svn: 190753

NetBSD need it.

llvm-svn: 190752

This is a fix to PR12778: in erroneous code an allocation function
can be declared with no arguments, quering the first argument in this case
causes assertion violation.

llvm-svn: 190751

llvm-svn: 190750

llvm-svn: 190749

This pass was based on the previous (essentially unused) profiling
infrastructure and the assumption that by ordering the basic blocks at
the IR level in a particular way, the correct layout would happen in the
end. This sometimes worked, and mostly didn't. It also was a really
naive implementation of the classical paper that dates from when branch
predictors were primarily directional and when loop structure wasn't
commonly available. It also didn't factor into the equation
non-fallthrough branches and other machine level details.

Anyways, for all of these reasons and more, I wrote
MachineBlockPlacement, which completely supercedes this pass. It both
uses modern profile information infrastructure, and actually works. =]

llvm-svn: 190748

Before:
  template <template <typename>
            class Fooooooo, template <typename>
            class Baaaaaaar>
  struct C {};

After:
  template <template <typename> class Fooooooo,
            template <typename> class Baaaaaaar>
  struct C {};

llvm-svn: 190747

llvm-svn: 190746

llvm-svn: 190745

llvm-svn: 190744

Summary:
We should treat a non-dependent template specialization like it wasn't
templated at all.

Reviewers: rsmith

CC: cfe-commits

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

llvm-svn: 190743

llvm-svn: 190742

and a mach kernel in all the pages of the core file.  If it finds
a user-process dyld binary, assume this is a user process that had
a copy of the mach kernel in memory when it crashed (e.g. lldb doing
kernel debugging) even though we found the kernel binary first.

Also, change the error messages about sections extending past the end
of the file to be warnings and make the messages sound less severe.
Most user process core files have one section that isn't included in
the file and there's no reason to worry people about that.

<rdar://problem/14473235> 

llvm-svn: 190741

llvm-svn: 190740

This case wasn't checked with a pointer condition.

llvm-svn: 190739

llvm-svn: 190738