Summary:
BranchInst, SwitchInst (with non-default case) with Undef as input is not
possible at this point. As we always default-fold terminator to one target in
ResolvedUndefsIn and set the input accordingly.

So we should only have constantint/blockaddress here.

If ConstantFoldTerminator fails, that could mean 2 things.

1. ConstantFoldTerminator is doing something unexpected, i.e. not folding on constantint
or blockaddress and not making blocks that should be dead dead.
2. This is not a terminator on constantint or blockaddress. Its on a constant or
overdefined, then this block should not be dead.

In both cases, we should assert.

Reviewers: davide, efriedma, sanjoy

Subscribers: llvm-commits

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

llvm-svn: 296281

Summary:
Migrated from grep to FileCheck.
Re-indented code, removed boilerplate comments.
Added 'entry' label at beginning of basic block.

Patch by Jorge Gorbe!

Subscribers: llvm-commits

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

llvm-svn: 296280

This reverts commit r296252 until 256-bit operations are more efficiently generated in X86.

llvm-svn: 296279

llvm-svn: 296278

No observable changes, spotted while looking at the scheduling description.

llvm-svn: 296277

llvm-svn: 296276

C++ DR1611, 1658, 2180: implement "potentially constructed subobject" rules for special member functions.

Essentially, as a base class constructor does not construct virtual bases, such
a constructor for an abstract class does not need the corresponding base class
construction to be valid, and likewise for destructors.

This creates an awkward situation: clang will sometimes generate references to
the complete object and deleting destructors for an abstract class (it puts
them in the construction vtable for a derived class). But we can't generate a
"correct" version of these because we can't generate references to base class
constructors any more (if they're template specializations, say, we might not
have instantiated them and can't assume any other TU will emit a copy).
Fortunately, we don't need to, since no correct program can ever invoke them,
so instead emit symbols that just trap.

We should stop emitting references to these symbols, but still need to emit
definitions for compatibility.

llvm-svn: 296275

llvm-svn: 296274

Summary:
Previously we used to return a bogus result, 0, for IR like `ashr %val,
-1`.

I've also added an assert checking that `ComputeNumSignBits` at least
returns 1.  That assert found an already checked in test case where we
were returning a bad result for `ashr %val, -1`.

Fixes PR32045.

Reviewers: spatel, majnemer

Reviewed By: spatel, majnemer

Subscribers: efriedma, mcrosier, llvm-commits

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

llvm-svn: 296273

The current pattern for extract bits in range is typically:

Mask.lshr(BitOffset).trunc(SubSizeInBits);

Which can be particularly slow for large APInts (MaskSizeInBits > 64) as they require the allocation of memory for the temporary variable.

This is another of the compile time issues identified in PR32037 (see also D30265).

This patch adds the APInt::extractBits() helper method which avoids the temporary memory allocation.

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

llvm-svn: 296272

llvm-svn: 296271

llvm-svn: 296270

llvm-svn: 296269

llvm-svn: 296268

llvm-svn: 296267

llvm-svn: 296266

Note quite sure why driver -target has no effect.

llvm-svn: 296265

[AVX-512] Remove unnecessary masked versions of VCVTSS2SD and VCVTSD2SS using the scalar register class. We only have patterns for the masked intrinsics.

llvm-svn: 296264

Attempt to fix the failing bots.

llvm-svn: 296263

This get the resource dir string to match with the one from libclang (which is not adding '/../'),
and allows clang to accept a modules-enabled PCH that was created by libclang.

llvm-svn: 296262

[modules] For -module-file-info, print out the resource dir path, since it is included in the module hash.

llvm-svn: 296261

[ExecutionDepsFix] Don't make copies of LiveReg objects when collecting operands for soft instructions

Summary:
While collecting operands we make copies of the LiveReg objects which are stored in the LiveRegs array. If the instruction uses the same register multiple times we end up with multiple copies. Later we iterate through the collected list of LiveReg objects and merge DomainValues. In the process of doing this the merge function can change the contents of the original LiveReg object in the LiveRegs array, but not the copies that have been made. So when we get to the second usage of the register we end up seeing a stale copy of the LiveReg object.

To fix this I've stopped copying and now just store a pointer to the original LiveReg object. Another option might be to avoid adding the same register to the Regs array twice, but this approach seemed simpler.

The included test case exposes this bug due to an AVX-512 masked OR instruction using the same register for the passthru operand and one of the inputs to the OR operation.

Fixes PR30284.

Reviewers: RKSimon, stoklund, MatzeB, spatel, myatsina

Reviewed By: RKSimon

Subscribers: llvm-commits

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

llvm-svn: 296260

llvm-svn: 296259

r296215, "[PDB] General improvements to Stream library."
r296217, "Disable BinaryStreamTest.StreamReaderObject temporarily."
r296220, "Re-enable BinaryStreamTest.StreamReaderObject."
r296244, "[PDB] Disable some tests that are breaking bots."
r296249, "Add static_cast to silence -Wc++11-narrowing."

std::errc::no_buffer_space should be used for OS-oriented errors for socket transmission.
(Seek discussions around llvm/xray.)

I could substitute s/no_buffer_space/others/g, but I revert whole them ATM.

Could we define and use LLVM errors there?

llvm-svn: 296258

llvm-svn: 296257

llvm-svn: 296256

llvm-svn: 296255

had missed most labels in this test because they didn't end
with a colon.

llvm-svn: 296254

When dumping .debug_info section we loop through all attributes mentioned in
.debug_abbrev section and dump values using DWARFFormValue::extractValue().
We need to skip implicit_const attributes here as their values are not
really located in .debug_info but directly in .debug_abbrev. This patch fixes
triggered assert() in DWARFFormValue::extractValue() caused by trying to
access implicit_const values from .debug_info.

llvm-svn: 296253

    Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner.

    * Simplify Consecutive Merge Store Candidate Search

    Now that address aliasing is much less conservative, push through
    simplified store merging search and chain alias analysis which only
    checks for parallel stores through the chain subgraph. This is cleaner
    as the separation of non-interfering loads/stores from the
    store-merging logic.

    When merging stores search up the chain through a single load, and
    finds all possible stores by looking down from through a load and a
    TokenFactor to all stores visited.

    This improves the quality of the output SelectionDAG and the output
    Codegen (save perhaps for some ARM cases where we correctly constructs
    wider loads, but then promotes them to float operations which appear
    but requires more expensive constant generation).

    Some minor peephole optimizations to deal with improved SubDAG shapes (listed below)

    Additional Minor Changes:

      1. Finishes removing unused AliasLoad code

      2. Unifies the chain aggregation in the merged stores across code
         paths

      3. Re-add the Store node to the worklist after calling
         SimplifyDemandedBits.

      4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is
         arbitrary, but seems sufficient to not cause regressions in
         tests.

      5. Remove Chain dependencies of Memory operations on CopyfromReg
         nodes as these are captured by data dependence

      6. Forward loads-store values through tokenfactors containing
          {CopyToReg,CopyFromReg} Values.

      7. Peephole to convert buildvector of extract_vector_elt to
         extract_subvector if possible (see
         CodeGen/AArch64/store-merge.ll)

      8. Store merging for the ARM target is restricted to 32-bit as
         some in some contexts invalid 64-bit operations are being
         generated. This can be removed once appropriate checks are
         added.

    This finishes the change Matt Arsenault started in r246307 and
    jyknight's original patch.

    Many tests required some changes as memory operations are now
    reorderable, improving load-store forwarding. One test in
    particular is worth noting:

      CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store
      forwarding converts a load-store pair into a parallel store and
      a memory-realized bitcast of the same value. However, because we
      lose the sharing of the explicit and implicit store values we
      must create another local store. A similar transformation
      happens before SelectionDAG as well.

    Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle

llvm-svn: 296252

Summary:
Fixed bunch of for loops to range based for loop
and bunch of rendundat types with auto.

Reviewers: echristo, silvas, chandlerc

Subscribers: mehdi_amini, llvm-commits

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

llvm-svn: 296251

llvm-svn: 296250

llvm-svn: 296249

There is a bot which doesn't use '%1' as the IR name of the first
argument to a function:

http://lab.llvm.org:8011/builders/clang-with-thin-lto-ubuntu/builds/2050/steps/test-stage1-compiler/logs/stdio

llvm-svn: 296248

llvm-svn: 296247

llvm-svn: 296246

2nd attempt: the first was in r296231, but it had a use after lifetime
bug.

Clang has logic to lower certain conditional expressions directly into llvm
select instructions. However, it does not emit the correct profile counter
increment as it does this: it emits an unconditional increment of the counter
for the 'then branch', even if the value selected is from the 'else branch'
(this is PR32019).

That means, given the following snippet, we would report that "0" is selected
twice, and that "1" is never selected:

  int f1(int x) {
    return x ? 0 : 1;
               ^2  ^0
  }

  f1(0);
  f1(1);

Fix the problem by using the instrprof_increment_step intrinsic to do the
proper increment.

llvm-svn: 296245

This has to do with big endian, but I can't fix it until
Monday.  The code itself is fine, just the tests are wrong.
Disabling 3 tests for now.

llvm-svn: 296244

match but the 'is_regex' argument was not passed as true.  Not sure
this is causing a bug, but noticed it while working on another bug.
These formatters gained a regex in r274489 for NDK but didn't pick
up the is_regex flag at the time.
<rdar://problem/30646077> 

llvm-svn: 296243

Summary: SimpleConstraintManager is difficult to use, and makes assumptions about capabilities of the constraint manager. This patch refactors out those portions into a new RangedConstraintManager, and also fixes some issues with camel case, formatting, and confusing naming.

Reviewers: zaks.anna, dcoughlin

Subscribers: mgorny, xazax.hun, NoQ, rgov, cfe-commits

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

llvm-svn: 296242