llvm-svn: 313808

The problems on the bots appear to be resolved and this was
determined to not be the culprit.  Removing this.

llvm-svn: 313807

Also add some tests that should be able to use v_mad_mixhi_f16,
but do not yet. This is trickier because we don't really model
the partial update of the register done by 16-bit instructions.

llvm-svn: 313806

Need to check for variables re-declarations when checking that the
variable was already captured in the captured region.

llvm-svn: 313805

This reverts commit r313798, it's causing buildbot failures.

llvm-svn: 313804

llvm-svn: 313803

llvm-svn: 313802

Caused by invalid order of members in ClangdServer.
DiagnosticsMutex was used after destruction.

llvm-svn: 313801

This patch goes back to considering ForceAbsolute in moveAbsRight, but
only if the second argument is not already absolute.

With this we can handle "foo + ABSOLUTE(foo)" and "ABSOLUTE(foo) + foo".

llvm-svn: 313800

llvm-svn: 313799

Summary: Resubmission of D37937. Fixed i386 target building (conversion from std::size_t& to uint64_t& failed). Fixed documentation warning failure about docs/CFIVerify.rst not being in the tree.

Reviewers: vlad.tsyrklevich

Reviewed By: vlad.tsyrklevich

Patch by Mitch Phillips

Subscribers: mgorny, pcc, llvm-commits, kcc

Differential Revision: https://reviews.llvm.org/D38089

llvm-svn: 313798

llvm-svn: 313797

This patch fixes broken preamble-skipping when the preamble region includes a byte order mark (BOM). Previously, parsing would fail if preamble PCH generation was enabled and a BOM was present.

This also fixes preamble invalidation when a BOM appears or disappears. This may seem to be an obscure edge case, but it happens regularly with IDEs that pass buffer overrides that never (or always) have a BOM, yet the underlying file from the initial parse that generated a PCH might (or might not) have a BOM.

I've included a test case for these scenarios.

Differential Revision: https://reviews.llvm.org/D37491

llvm-svn: 313796

Add adds support for naming data segments.  This is useful
useful linkers so that they can merge similar sections.

Differential Revision: https://reviews.llvm.org/D37886

llvm-svn: 313795

The idea of this function is to simplify the implementation of binary
operators like add.

A value might be absolute because of an ABSOLUTE expression, but it
still depends on the value of a section and we might not be able to
evaluate it early. We should keep such values on the LHS, so that we
can delay the evaluation.

We can now handle both "1 + ABSOLUTE(foo)" and "ABSOLUTE(foo) + 1".

llvm-svn: 313794

llvm-svn: 313793

[InstCombine] Use APInt::getActiveBits() to avoid creating an APInt from a trailing zero count to do a comparison. NFCI

llvm-svn: 313792

Add support for passing SwiftError through a register on the Windows x64
calling convention.  This allows the use of swifterror attributes on
parameters which is used by the swift front end for the `Error`
parameter.  This partially enables building the swift standard library
for Windows x86_64.

llvm-svn: 313791

This enables readobj to output Windows resource files (.res). This way,
we'll be able to test .res outputs without comparing them byte-by-byte
with "magic binary files" generated by MS toolchain.

Differential Revision: https://reviews.llvm.org/D38058

llvm-svn: 313790

Mark the __eval methods on independent_bits_engine (and __independent_bits_engine) as const, since they make no changes to the object. NFC.

llvm-svn: 313789

The previous logic was to try to detect if a linker script defined _gp
by checking !ElfSym::MipsGp->Value. That doesn't work in all cases as
the assigned value can be 0.

We now just always defined it Writer.cpp and always overwrite it
afterwards if needed.

llvm-svn: 313788

This patch renames K_MIPS64 to K_GNU64 as part of a change to add
support for writing archives with 64-bit indexes in the symbol table.

llvm-svn: 313787

After r313775, it's easier to maintain a parallel BitVector of spilled
locations indexed by location number.

I wasn't able to build a good reduced test case for this iteration of
the bug, but I added a more direct assertion that spilled values must
use frame index locations. If this bug reappears, it won't only fire on
the NEON vector code that we detected it on, but on medium-sized
integer-only programs as well.

llvm-svn: 313786

1. Fix a data race (g_interrupt_sent flag usage was not thread safe, signals
can be handled on arbitrary threads)

2. exit() is not signal-safe, replaced it with the signal-safe equivalent
_exit()

(This differs from the patch on Phabrictor because I had to add
`#include <atomic>` to get the definition of `std::atomic_flag`.)

patch by lemo

Differential Revision: https://reviews.llvm.org/D37926

llvm-svn: 313785

Differential Revision: https://reviews.llvm.org/D37042

llvm-svn: 313784

This changes some STL data types to corresponding LLVM
data types that have better performance characteristics.

Differential Revision: https://reviews.llvm.org/D37957

llvm-svn: 313783

No functional change, just adding a DenseMapInfo and tombstone
value so that MVT's can be put into a DenseMap / DenseSet.

llvm-svn: 313782

This broke the buildbots, e.g.
http://bb.pgr.jp/builders/test-llvm-i686-linux-RA/builds/391

> Summary:
> This patch tries to vectorize loads of consecutive memory accesses, accessed
> in non-consecutive or jumbled way. An earlier attempt was made with patch D26905
> which was reverted back due to some basic issue with representing the 'use mask'
> jumbled accesses.
>
> This patch fixes the mask representation by recording the 'use mask' in the usertree entry.
>
> Change-Id: I9fe7f5045f065d84c126fa307ef6ebe0787296df
>
> Subscribers: mzolotukhin
>
> Reviewed By: ayal
>
> Differential Revision: https://reviews.llvm.org/D36130
>
> Review comments updated accordingly
>
> Change-Id: I22ab0a8a9bac9d49d74baa81a08e1e486f5e75f0
>
> Added a TODO for sortLoadAccesses API
>
> Change-Id: I3c679bf1865422d1b45e17ea28f1992bca660b58
>
> Modified the TODO for sortLoadAccesses API
>
> Change-Id: Ie64a66cb5f9e2a7610438abb0e750c6e090f9565
>
> Review comment update for using OpdNum to insert the mask in respective location
>
> Change-Id: I016d0c1b29874e979efc0205bbf078991f92edce
>
> Fixes '-Wsign-compare warning' in LoopAccessAnalysis.cpp and code rebase
>
> Change-Id: I64b2ea5e68c1d7b6a028f5ef8251c5a97333f89b

llvm-svn: 313781

llvm-svn: 313780

llvm-svn: 313779

This patch implements the Darwin dwarfdump option --recurse-depth=<N>,
which limits the recursion depth when selectively printing DIEs at an
offset.

Differential Revision: https://reviews.llvm.org/D38064

llvm-svn: 313778

Normally to find the offset of a value in a section, we have to
compute the value since the alignment is defined on the final address.

If the alignment is trivial, we can skip the value computation. This
allows us to know the offset even in cases where we cannot yet know
the value.

llvm-svn: 313777

llvm-svn: 313776

Summary:
The new code should be linear in the number of DBG_VALUEs, while the old
code was quadratic. NFC intended.

This is also hopefully a more direct expression of the problem, which is
to:

1. Rewrite all virtual register operands to stack slots or physical
   registers
2. Uniquely number those machine operands, assigning them location
   numbers
3. Rewrite all uses of the old location numbers in the interval map to
   use the new location numbers

In r313400, I attempted to track which locations were spilled in a
parallel bitvector indexed by location number. My code was broken
because these location numbers are not stable during rewriting.

Reviewers: aprantl, hans

Subscribers: hiraditya, llvm-commits

Differential Revision: https://reviews.llvm.org/D38068

llvm-svn: 313775

In these cases, two selects have constant selectable operands for
both the true and false components and have the same conditional
expression.
We then create two arithmetic operations of the same type and feed a
final select operation using the result of the true arithmetic for the true
operand and the result of the false arithmetic for the false operand and reuse
the original conditionl expression.
The arithmetic operations are naturally folded as a consequence, leaving
only the newly formed select to replace the old arithmetic operation.

Patch by: Michael Berg <michael_c_berg@apple.com>
Differential Revision: https://reviews.llvm.org/D37019

llvm-svn: 313774

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 313773

I did not upload two binaries that I reference in tests.

This change adds support for sections involved in dynamic loading such
as SHT_DYNAMIC, SHT_DYNSYM, and allocated string tables.

The two added binaries used for tests can be downloaded here and here

Differential Revision: https://reviews.llvm.org/D36560

llvm-svn: 313772

Summary:
This patch tries to vectorize loads of consecutive memory accesses, accessed
in non-consecutive or jumbled way. An earlier attempt was made with patch D26905
which was reverted back due to some basic issue with representing the 'use mask'
jumbled accesses.

This patch fixes the mask representation by recording the 'use mask' in the usertree entry.

Change-Id: I9fe7f5045f065d84c126fa307ef6ebe0787296df

Subscribers: mzolotukhin

Reviewed By: ayal

Differential Revision: https://reviews.llvm.org/D36130

Review comments updated accordingly

Change-Id: I22ab0a8a9bac9d49d74baa81a08e1e486f5e75f0

Added a TODO for sortLoadAccesses API

Change-Id: I3c679bf1865422d1b45e17ea28f1992bca660b58

Modified the TODO for sortLoadAccesses API

Change-Id: Ie64a66cb5f9e2a7610438abb0e750c6e090f9565

Review comment update for using OpdNum to insert the mask in respective location

Change-Id: I016d0c1b29874e979efc0205bbf078991f92edce

Fixes '-Wsign-compare warning' in LoopAccessAnalysis.cpp and code rebase

Change-Id: I64b2ea5e68c1d7b6a028f5ef8251c5a97333f89b
llvm-svn: 313771

This adds an LLVM_ENABLE_IR_PGO option to enable building llvm and its
tools with IR PGO instrumentation.

Usage: -DLLVM_BUILD_INSTRUMENTED=On -DLLVM_ENABLE_IR_PGO=On (both
options must be enabled)

Differential Revision: https://reviews.llvm.org/D38066

llvm-svn: 313770

The coverage bot has been stable for a while:

  http://lab.llvm.org:8080/coverage/coverage-reports/index.html

llvm-svn: 313769