llvm-svn: 296302

llvm-svn: 296301

llvm-svn: 296300

[APInt] Remove unnecessary early out from getLowBitsSet. The same case is handled equally well by the next check.

llvm-svn: 296299

llvm-svn: 296298

Pointed out by Piotr Padlewski.

llvm-svn: 296297

The DAZ feature introduces the denormal zero support for x86.
Currently the definitions are located under SSE3 header, however there are some SSE2 targets that support the feature as well.

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

llvm-svn: 296296

This reverts commit r296149 as it leads to crashes when compiling for
PPC.

llvm-svn: 296295

llvm-svn: 296294

llvm-svn: 296293

llvm-svn: 296292

llvm-svn: 296291

llvm-svn: 296290

[AVX-512] Disable the redundant patterns in the VPBROADCASTBr_Alt and VPBROADCASTWr_Alt instructions. NFC

llvm-svn: 296289

llvm-svn: 296288

llvm-svn: 296287

llvm-svn: 296286

llvm-svn: 296285

llvm-svn: 296284

[X86] Add an additional CHECK prefix to a test. Some of the cases used it, but it wasn't on the FileCheck command lines.

llvm-svn: 296283

[index] Add 'Parameter' symbol kind and 'Local' symbol property to distinguish function-local symbols

Parameters have a 'child' relation to their function/method.
Also add an option '-include-locals' to 'c-index-test core' to enable indexing of function-local symbols.

Original patch from Nathan Hawes with some changes by me.
https://reviews.llvm.org/D30304

llvm-svn: 296282

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