Summary:
This patch is an attempt at making `DenseMapIterator`s "fail-fast".
Fail-fast iterators that have been invalidated due to insertion into
the host `DenseMap` deterministically trip an assert (in debug mode)
on access, instead of non-deterministically hitting memory corruption
issues.

Enabling fail-fast iterators breaks the LLVM C++ ABI, so they are
predicated on `LLVM_ENABLE_ABI_BREAKING_CHECKS`.
`LLVM_ENABLE_ABI_BREAKING_CHECKS` by default flips with
`LLVM_ENABLE_ASSERTS`, but can be clamped to ON or OFF using the CMake /
autoconf build system.

Reviewers: chandlerc, dexonsmith, rnk, zturner

Subscribers: llvm-commits

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

llvm-svn: 233310

The "|&" operator isn't POSIX, so it can fail depending on the host's
default shell. Avoid it.

There were also a couple of places that did "2>1", but this creates a
file called "1". They clearly meant "2>&1".

llvm-svn: 233309

Can avoid a problem if tools/clang/tools/extra is in the tree.

Patch by Douglas Yung!

llvm-svn: 233307

llvm-svn: 233305

Enabled by default, but it's useful when debugging with llc.

Patch by Ranjeet Singh.

llvm-svn: 233303

This reverts commit r233254, effectively reapplying r233164 (and its
successors), with an additional testcase for when subprograms match
exactly.  This fixes PR22792 (again).

I'm using the same approach, but I've moved up the call to
`stripReplacedSubprograms()`.  The function pointers need to be dropped
before mapping any metadata from the source module, or else this can
drop the function from new subprograms that have merged (via Metadata
uniquing) with the old ones.  Dropping the pointers first prevents them
from merging.

**** The original commit message follows. ****

Linker: Drop function pointers for overridden subprograms

Instead of dropping subprograms that have been overridden, just set
their function pointers to `nullptr`.  This is a minor adjustment to the
stop-gap fix for PR21910 committed in r224487, and fixes the crasher
from PR22792.

The problem that r224487 put a band-aid on: how do we find the canonical
subprogram for a `Function`?  Since the backend currently relies on
`DebugInfoFinder` (which does a naive in-order traversal of compile
units and picks the first subprogram) for this, r224487 tried dropping
non-canonical subprograms.

Dropping subprograms fails because the backend *also* builds up a map
from subprogram to compile unit (`DwarfDebug::SPMap`) based on the
subprogram lists.  A missing subprogram causes segfaults later when an
inlined reference (such as in this testcase) is created.

Instead, just drop the `Function` pointer to `nullptr`, which nicely
mirrors what happens when an already-inlined `Function` is optimized
out.  We can't really be sure that it's the same definition anyway, as
the testcase demonstrates.

This still isn't completely satisfactory.  Two flaws at least that I can
think of:

  - I still haven't found a straightforward way to make this symmetric
    in the IR.  (Interestingly, the DWARF output is already symmetric,
    and I've tested for that to be sure we don't regress.)
  - Using `DebugInfoFinder` to find the canonical subprogram for a
    function is kind of crazy.  We should just attach metadata to the
    function, like this:

        define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) {

llvm-svn: 233302

Reviewers: t.p.northover

Subscribers: llvm-commits

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

llvm-svn: 233301

Third element is to be added soon to "struct AArch64NamedImmMapper::Mapping". So its instances are renamed from ...Pairs to ...Mappings

Reviewers: jmolloy

Subscribers: llvm-commits

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

llvm-svn: 233300

class AArch64NamedImmMapper is to become dependent of SubTargetFeatures, while class AArch64Operand don't have access to the latter. 

So, AArch64NamedImmMapper constructor invocations are refactored away from methods of AArch64Operand.

Reviewers: jmolloy

Subscribers: llvm-commits

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

llvm-svn: 233297

Summary:
With the introduction of MarkPendingLoopPredicates in r157092, I don't
think the bailout is needed anymore.

Reviewers: atrick, nicholas

Subscribers: llvm-commits

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

llvm-svn: 233296

llvm-svn: 233294

llvm-svn: 233293

llvm-svn: 233292

Anding and comparing with zero can be done in a single instruction on
most archs so this is a bit cheaper.

llvm-svn: 233291

New architecture and cpu added, following http://community.arm.com/groups/processors/blog/2014/12/02/the-armv8-a-architecture-and-its-ongoing-development

Reviewers: t.p.northover

Subscribers: llvm-commits

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

llvm-svn: 233290

llvm-svn: 233289

llvm-svn: 233288

Summary:
This patch enhances SLSR to handle another candidate form &B[i * S]. If
we found two candidates

S1: X = &B[i * S]
S2: Y = &B[i' * S]

and S1 dominates S2, we can replace S2 with

Y = &X[(i' - i) * S]

Test Plan:
slsr-gep.ll
X86/no-slsr.ll: verify that we do not run SLSR on GEPs that already fit into
an addressing mode

Reviewers: eliben, atrick, meheff, hfinkel

Reviewed By: hfinkel

Subscribers: sanjoy, llvm-commits

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

llvm-svn: 233286

Sometimes report_fatal_error is called when there is not a handler function used to fail gracefully. In that case, RunInterruptHandlers is called, which attempts to enter a critical section object. Ensure that the critical section is properly initialized so that this code functions properly, and tools like clang-tidy do not crash in Debug builds.

llvm-svn: 233282

Summary: This groups all of the MipsAssemblerOptions functionality together, making it more reader-friendly.

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: llvm-commits

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

llvm-svn: 233271

This patch teaches fast-isel how to select 128-bit vector load instructions.
Added test CodeGen/X86/fast-isel-vecload.ll

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

llvm-svn: 233270

This reverts commit r233164 and its testcase follow-ups in r233165,
r233207, r233214, and r233221.  It apparently unleashed an LTO bootstrap
failure, at least on Darwin:

http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_build/3376/

I'm reproducing now.

llvm-svn: 233254

Like r233229 for `llvm-link`, start verifying input files to `bugpoint`.

llvm-svn: 233253

llvm-svn: 233252

those are in the same basic block.
The previous approach was the topological order of the basic block.

By default this rule is disabled.

Related to PR22768.

llvm-svn: 233241

llvm-svn: 233240

for PPC due to some unfortunate default setting via TargetMachine
creation. I've added a FIXME on how this can be unraveled in the
backend and a test to make sure we successfully legalize 64-bit things
if we say we're 64-bits.

llvm-svn: 233239

Otherwise, broken input modules can cause assertions.  I've updated two
of the testcases that started failing (modules that had `Require` flags
but didn't meet their own requirements), but Rafael and I decided that
test/Linker/2011-08-22-ResolveAlias.ll should just be deleted outright
-- it's a leftover of the way llvm-gcc used to implement weakref.

llvm-svn: 233229

llvm-svn: 233226

Summary:
`ComputeNumSignBits` returns incorrect results for `srem` instructions.
This change fixes the issue and adds a test case.

Reviewers: nadav, nicholas, atrick

Subscribers: llvm-commits

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

llvm-svn: 233225

This patch adds supports for the vector constant folding of TRUNCATE and FP_EXTEND instructions and tidies up the SINT_TO_FP and UINT_TO_FP instructions to match.

It also moves the vector constant folding for the FNEG and FABS instructions to use the DAG.getNode() functionality like the other unary instructions.

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

llvm-svn: 233224

As dblaikie pointed out, if I stop setting `emissionKind: 2` then the
backend won't do magical things on Linux vs. Darwin.  I had wrongly
assumed that there were stricter requirements on the input if we weren't
in line-tables-only mode, but apparently not.

With that knowledge, clean up this testcase a little more.

  - Set `emissionKind: 1`.
  - Add back checks for the weak version of @foo.
  - Check more robustly that we have the right subprograms by checking
    the `DW_AT_decl_file` and `DW_AT_decl_line` which now show up.
  - Check the line table in isolation (since it's no longer doubling as
    an indirect test for the subprogram of the weak version of @foo).

llvm-svn: 233221

llvm-svn: 233220

If liveranges induced by an IMPLICIT_DEF get completely covered by a
proper liverange the IMPLICIT_DEF instructions and its corresponding
definitions have to be removed from the live ranges. This has to happen
in the subregister live ranges as well (I didn't see this case earlier
because in most programs only some subregisters are covered and the
IMPLCIT_DEF won't get removed).

No testcase, I spent hours trying to create one for one of the public
targets, but ultimately failed because I couldn't manage to properly
control the placement of COPY and IMPLICIT_DEF instructions from an .ll
file.

llvm-svn: 233217

llvm-svn: 233216

According to at least one bot [1], function prologues aren't always
empty for these functions.  Skip that part of the follow-up check.

llvm-svn: 233214

llvm-svn: 233213

We don't have any logic to emit those tables yet, so the sdag lowering
of this intrinsic is just a stub. We can see the intrinsic in the
prepared IR, though.

llvm-svn: 233209

Rewrite the checks from r233164 that I temporarily disabled in r233165.

It turns out that the line-tables only debug info we emit from `llc` is
(intentionally) different on Linux than on Darwin.  r218129 started
skipping emission of subprograms with no inlined subroutines, and
r218702 was a spiritual revert of that behaviour for Darwin.

I think we can still test this in a platform-neutral way.

  - Stop checking for the possibly missing `DW_TAG_subprogram` defining
    the debug info for the real version of `@foo`.
  - Start checking the line tables, ensuring that the right debug info
    was used to generate them (grabbing `DW_AT_low_pc` from the compile
    unit).
  - I changed up the line numbers used in the "weak" version so it's
    easier to follow.

This should hopefully finish off PR22792.

llvm-svn: 233207

llvm-svn: 233206