The tool reports verbose output for the DWARF debug location coverage.
The llvm-locstats for each variable or formal parameter DIE computes what
percentage from the code section bytes, where it is in scope, it has
location description. The line 0 shows the number (and the percentage) of
DIEs with no location information, but the line 100 shows the number (and
the percentage) of DIEs where there is location information in all code
section bytes (where the variable or parameter is in the scope). The line
50..59 shows the number (and the percentage) of DIEs where the location
information is in between 50 and 59 percentage of its scope covered.

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

llvm-svn: 372554

[lldb] Fix that importing decls in a TagDecl end up in wrong declaration context (partly reverts D61333)

Summary:
In D61333 we dropped some code from ClangASTSource that checks if imported declarations
ended up in the right DeclContext. While this code wasn't tested by the test suite (or better, it was hit
by the test suite but we didn't have any checks that were affected) and the code seems pointless
(as usually Decls should end up in the right DeclContext), it actually broke the data formatters in LLDB
and causes a bunch of obscure bugs where structs suddenly miss all their members. The first report we got about
this was that printing a std::map doesn't work anymore when simply doing "expr m" (m is the std::map).

This patch reverts D61333 partly and reintroduces the check in a more stricter way (we actually check now that
we *move* the Decl and it is in a single DeclContext). This should fix all the problems we currently have until
we figure out how to properly fix the underlying issues. I changed the order of some std::map formatter tests
which is currently the most reliable way to test this problem (it's a tricky setup, see description below).

Fixes rdar://55502701 and rdar://55129537

--------------------------------------

Some more explanation what is actually going on and what is going wrong:

The situation we have is that if we have a `std::map m` and do a `expr m`, we end up seeing an empty map
(even if `m` has elements). The reason for this is that our data formatter sees that std::pair<int, int> has no
members. However, `frame var m` works just fine (and fixes all following `expr m` calls).

The reason for why `expr` breaks std::map is that we actually copy the std::map nodes in two steps in the
three ASTContexts that are involved: The debug information ASTContext (D-AST), the expression ASTContext
we created for the current expression (E-AST) and the persistent ASTContext we use for our $variables (P-AST).

When doing `expr m` we do a minimal import of `std::map` from D-AST to E-AST just do the type checking/codegen.
This copies std::map itself and does a minimal.import of `std::pair<int, int>` (that is, we don't actually import
the `first` and `second` members as we don't need them for anything). After the expression is done, we take
the expression result and copy it from E-AST to P-AST. This imports the E-AST's `std::pair` into P-AST which still
has no `first` and `second` as they are still undeserialized. Once we are in P-AST, the data formatter tries to
inspect `std::map` (and also `std::pair` as that's what the elements are) and it asks for the `std::pair` members.
We see that `std::pair` has undeserialized members and go to the ExternalASTSource to ask for them. However,
P-ASTs ExternalASTSource points to D-AST (and not E-AST, which `std::pair` came from). It can't point to E-AST
as that is only temporary and already gone (and also doesn't actually contain all decls we have in P-AST).

So we go to D-AST to get the `std::pair` members. The ASTImporter is asked to copy over `std::pair` members
and first checks if `std::pair` is already in P-AST. However, it only finds the std::pair we got from E-AST, so it
can't use it's map of already imported declarations and does a comparison between the `std::pair` decls we have
Because the ASTImporter thinks they are different declarations, it creates a second `std::pair` and fills in the
members `first` and `second` into the second `std::pair`. However, the data formatter is looking at the first
`std::pair` which still has no members as they are in the other decl. Now we pretend we have no declarations
and just print an empty map as a fallback.

The hack we had before fixed this issue by moving `first` and `second` to the first declaration which makes
the formatters happy as they can now see the members in the DeclContext they are querying.

Obviously this is a temporary patch until we get a real fix but I'm not sure what's the best way to fix this.
Implementing that the ClassTemplateSpecializationDecl actually understands that the two std::pair's are the same
decl fixes the issue, but this doesn't fix the bug for all declarations. My preferred solution would be to
complete all declarations in E-AST before they get moved to P-AST (as we anyway have to do this from what I can
tell), but that might have unintended side-effects and not sure what's the best way to implement this.

Reviewers: friss, martong

Reviewed By: martong

Subscribers: aprantl, rnkovacs, christof, abidh, JDevlieghere, lldb-commits, shafik

Tags: #lldb

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

llvm-svn: 372549

llvm-svn: 372548

Revert "Extension: Mark the default constructor of chrono::duration as conditionally noexcept"; this breaks the gcc5 bot for C++11

This reverts commit c8ca15c95c4c0d6d1356500d5fe49a319ea4ca01.

llvm-svn: 372546

llvm-svn: 372544

[X86] Remove SETEQ/SETNE canonicalization code from LowerIntVSETCC_AVX512 to prevent an infinite loop.

The attached test case would previous infinite loop after
r365711.

I'm going to move this to X86ISelDAGToDAG.cpp to get the setcc
to match VPTEST in 32-bit mode in a follow up commit.

llvm-svn: 372543

llvm-svn: 372542

destructors.

llvm-svn: 372541

When AVX512 is available and the preferred vector width is 512-bits or
more, we should prefer AVX512 for memcpy().

https://bugs.llvm.org/show_bug.cgi?id=43240

https://reviews.llvm.org/D67874

llvm-svn: 372540

llvm-svn: 372539

appropriate during constant evaluation.

Note that the evaluator is sometimes invoked on incomplete expressions.
In such cases, if an object is constructed but we never reach the point
where it would be destroyed (and it has non-trivial destruction), we
treat the expression as having an unmodeled side-effect.

llvm-svn: 372538

[X86] Convert to Constant arguments to MMX shift by i32 intrinsics to TargetConstant during lowering.

This allows us to use timm in the isel table which is more
consistent with other intrinsics that take an immediate now.

We can't declare the intrinsic as taking an ImmArg because we
need to match non-constants to the shift by MMX register
instruction which we do by mutating the intrinsic id during
lowering.

llvm-svn: 372537

This goes back to when MMX was migrated to intrinsic only. The
hack referenced here has been gone for quite a while.

llvm-svn: 372536

[X86][SelectionDAGBuilder] Move the hack for handling MMX shift by i32 intrinsics into the X86 backend.

This intrinsics should be shift by immediate, but gcc allows any
i32 scalar and clang needs to match that. So we try to detect the
non-constant case and move the data from an integer register to an
MMX register.

Previously this was done by creating a v2i32 build_vector and
bitcast in SelectionDAGBuilder. This had to be done early since
v2i32 isn't a legal type. The bitcast+build_vector would be DAG
combined to X86ISD::MMX_MOVW2D which isel will turn into a
GPR->MMX MOVD.

This commit just moves the whole thing to lowering and emits
the X86ISD::MMX_MOVW2D directly to avoid the illegal type. The
test changes just seem to be due to nodes being linearized in a
different order.

llvm-svn: 372535

[X86] Require last argument to LWPINS/LWPVAL builtins to be an ICE. Add ImmArg to the llvm intrinsics.

Update the isel patterns to use timm instead of imm.

llvm-svn: 372534

llvm-svn: 372533

[X86] X86DAGToDAGISel::matchBEXTRFromAndImm(): if can't use BEXTR, fallback to BZHI is profitable (PR43381)

Summary:
PR43381 notes that while we are good at matching `(X >> C1) & C2` as BEXTR/BEXTRI,
we only do that if we either have BEXTRI (TBM),
or if BEXTR is marked as being fast (`-mattr=+fast-bextr`).
In all other cases we don't match.

But that is mainly only true for AMD CPU's.
However, for all the CPU's for which we have sched models,
the BZHI is always fast (or the sched models are all bad.)

So if we decide that it's unprofitable to emit BEXTR/BEXTRI,
we should consider falling-back to BZHI if it is available,
and follow-up with the shift.

While it's really tempting to do something because it's cool
it is wise to first think whether it actually makes sense to do.
We shouldn't just use BZHI because we can, but only it it is beneficial.
In particular, it isn't really worth it if the input is a register,
mask is small, or we can fold a load.
But it is worth it if the mask does not fit into 32-bits.

(careful, i don't know much about intel cpu's, my choice of `-mcpu` may be bad here)
Thus we manage to fold a load:
https://godbolt.org/z/Er0OQz
Or if we'd end up using BZHI anyways because the mask is large:
https://godbolt.org/z/dBJ_5h
But this isn'r actually profitable in general case,
e.g. here we'd increase microop count
(the register renaming is free, mca does not model that there it seems)
https://godbolt.org/z/k6wFoz
Likewise, not worth it if we just get load folding:
https://godbolt.org/z/1M1deG

https://bugs.llvm.org/show_bug.cgi?id=43381

Reviewers: RKSimon, craig.topper, davezarzycki, spatel

Reviewed By: craig.topper, davezarzycki

Subscribers: andreadb, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 372532

Extracted from D63082. GCC has this warning under -Wint-in-bool-context, but as noted in the D63082's review, we should put it under TautologicalConstantCompare.

llvm-svn: 372531

Summary: not every read in CXXConstructorDecl::getExplicitSpecifierInternal() was made on the canonical declaration.

Reviewers: rsmith, aaron.ballman

Reviewed By: rsmith

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 372530

The static analyzer is warning about potential null dereferences, but we should be able to use cast<VectorType> directly and if not assert will fire for us.

llvm-svn: 372529

[AMDGPU] isSDNodeAlwaysUniform - silence static analyzer dyn_cast<LoadSDNode> null dereference warning. NFCI.

The static analyzer is warning about a potential null dereference, but we should be able to use cast<LoadSDNode> directly and if not assert will fire for us.

llvm-svn: 372528

Add a 'leak_sanitizer' feature akin to existing '*_sanitizer' features
to let programmers switch code paths accounting for leak sanitizers
being enabled.

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

llvm-svn: 372527

This seems to have completed omitted any check for the opcode
of the operand in the isel table.

llvm-svn: 372526

[X86][TableGen] Allow timm to appear in output patterns. Use it to remove ConvertToTarget opcodes from the X86 isel table.

We're now using a lot more TargetConstant nodes in SelectionDAG.
But we were still telling isel to convert some of them
to TargetConstants even though they already are. This is because
isel emits a conversion anytime the output pattern has a an 'imm'.
I guess for patterns in instructions we take the 'timm' from the
'set' pattern, but for Pat patterns with explcicit output we
previously had to say 'imm' since 'timm' wasn't allowed in outputs.

llvm-svn: 372525

llvm-svn: 372524

We need to match TargetConstant, not Constant. This was broken
in r372338, but we lacked test coverage.

llvm-svn: 372523

Some of the isel patterns were not updated to check for
TargetConstant instead of Constant in r372338.

llvm-svn: 372522

Merge the calls, just adjust the demandedelts if we have a valid extract_subvector constant index, else demand all elts.

llvm-svn: 372521

llvm-svn: 372520

Add assertions to make it clear that GenerateIVChain / NarrowSearchSpaceByPickingWinnerRegs should succeed in finding non-null values

llvm-svn: 372518

llvm-svn: 372517

Commit c15aa241 ("[CLANG][BPF] change __builtin_preserve_access_index()
signature") changed the builtin function signature to
  PointerT __builtin_preserve_access_index(PointerT ptr)
with a pointer type as the argument/return type, where argument and
return types must be the same.

There is really no reason for this constraint. The builtin just
presented a code region so that IR builtins
  __builtin_{array, struct, union}_preserve_access_index
can be applied.

This patch removed the pointer type restriction to permit any
argument type as long as it is permitted by the compiler.

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

llvm-svn: 372516

llvm-svn: 372515

The AVX512 cases still need some work to correct recognise the PMOV truncation cases.

llvm-svn: 372514

In case of linking binary blobs which do not have any ELF headers, we can
deduce MIPS ABI  ELF header flags from an `emulation` option.

Patch by Kyle Evans.

llvm-svn: 372513

No behavior change.

llvm-svn: 372512

This fixes buildbot failures for https://reviews.llvm.org/rL372459.
(at least on PowerPC/Z )

The fix is generated by running clang-format on the error lines only.

llvm-svn: 372511

This has the potential to uncover missed analysis/folds as shown in the
min/max code comment/test, but fewer restrictions on icmp folds should
be better in general to solve cases like:
https://bugs.llvm.org/show_bug.cgi?id=43310

llvm-svn: 372510

llvm-svn: 372509

llvm-svn: 372508