[lldb] Reduce some dangerous boilerplate with CompletionRequest::ShiftArguments

We should in general not allow external code to fiddle with the internals of
CompletionRequest, but until this is gone let's at least provide a utility
function that makes this less dangerous.

This also now correct updates the partially parsed argument list,
but it doesn't seem to be used by anything that is behind one of
the current shift/SetCursorIndex calls, so this doesn't seeem to
fix any currently used completion.

llvm-svn: 372556

[MIPS GlobalISel] VarArg argument lowering, select G_VASTART and vacopy

CC_Mips doesn't accept vararg functions for O32, so we have to explicitly
use CC_Mips_FixedArg.
For lowerCall we now properly figure out whether callee function is vararg
or not, this has no effect for O32 since we always use CC_Mips_FixedArg.
For lower formal arguments we need to copy arguments in register to stack
and save pointer to start for argument list into MipsMachineFunction
object so that G_VASTART could use it during instruction select.
For vacopy we need to copy content from one vreg to another,
load and store are used for that purpose.

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

llvm-svn: 372555

Reland "[utils] Implement the llvm-locstats tool"

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

[lldb] Fix LLDB build after r372538

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

[X86] Canonicalize all zeroes vector to RHS in X86DAGToDAGISel::tryVPTESTM.

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

[X86] Add 32-bit command line to avx512f-vec-test-testn.ll

llvm-svn: 372542

For P0784R7: add further testing of requirements on constexpr
destructors.

llvm-svn: 372541

Prefer AVX512 memcpy when applicable

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

Extension: Mark the default constructor of chrono::duration as conditionally noexcept

llvm-svn: 372539

For P0784R7: add support for constexpr destructors, and call them as
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

[X86] Remove stale FIXME.

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

[NFC] Fixed failed test

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

[Diagnostics] Warn if ?: with integer constants always evaluates to true

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

[clang] fixing conditional explicit for out-of-line definition PR42980

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

Verifier - silence static analyzer dyn_cast<VectorType> null dereference warnings. NFCI.

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

[clang] [Basic] Enable __has_feature(leak_sanitizer)

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

[X86] Fix some VCVTPS2PH isel patterns where 'i32' was used instead of 'timm'

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

[NFC][X86] Add BEXTR test with load and 33-bit mask (PR43381 / D67875)

llvm-svn: 372524

[X86] Update commutable EVEX vcmp patterns to use timm instead of imm.

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

llvm-svn: 372523

[X86] Add more tests for commuting evex vcmp instructions during isel to fold a load.

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

llvm-svn: 372522

[SelectionDAG] computeKnownBits/ComputeNumSignBits - cleanup demanded/unknown paths. NFCI.

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

llvm-svn: 372521

[XRay] Silence static analyzer dyn_cast<BufferExtents> null dereference warning. NFCI.

llvm-svn: 372520

[LSR] Silence static analyzer null dereference warnings with assertions. NFCI.

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

llvm-svn: 372518

ConstantHoisting - Silence static analyzer dyn_cast<PointerType> null dereference warning. NFCI.

llvm-svn: 372517

[CLANG][BPF] permit any argument type for __builtin_preserve_access_index()

Commit c15aa241f821 ("[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

gn build: Friendlier error on invalid entries in llvm_targets_to_build

llvm-svn: 372515

[Cost][X86] Add more missing vector truncation costs

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

llvm-svn: 372514

[mips] Deduce MIPS specific ELF header flags from `emulation`

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

gn build: consolidate "Nothing to do" branches in targets.gni

No behavior change.

llvm-svn: 372512

[compiler-rt] Fix lint check failure on comments

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

[InstCombine] allow icmp+binop folds before min/max bailout (PR43310)

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

[InstCombine] add tests for icmp fold hindered by min/max; NFC

llvm-svn: 372509

Fix uninitialized variable warning. NFCI.

llvm-svn: 372508

[AArch64] AArch64StackTagging - Silence static analyzer dyn_cast<> null dereference warning. NFCI.

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

llvm-svn: 372507

gn build: Add missing RISCV to llvm_targets_to_build="all"

llvm-svn: 372506

gn build: Add build files for llvm/lib/Target/AVR

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

llvm-svn: 372505

[NVPTX] NVPTXLowerAggrCopies - Silence static analyzer dyn_cast<StoreInst> null dereference warning. NFCI.

llvm-svn: 372504

[Lanai] LanaiAsmParser - Silence static analyzer dyn_cast null dereference warnings. NFCI.

We were already doing this dyn_cast && isa<> && cast<> pattern for some add*Operands methods, just do this more consistently to stop clang static analyzer warning so much.

llvm-svn: 372503

[VPlan] Silence static analyzer dyn_cast null dereference warning. NFCI.

llvm-svn: 372502

AMDGPUPrintfRuntimeBinding - silence static analyzer null dereference warnings. NFCI.

llvm-svn: 372501

[MIPS] Don't dereference dyn_cast<> Constant results. NFCI.

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

llvm-svn: 372500

[Hexagon] Don't dereference dyn_cast<ConstantFPSDNode> result. NFCI.

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

llvm-svn: 372499

[Cost][X86] Add v2i64 truncation costs

We are missing costs for a lot of truncation cases, I'm hoping to address all the 'zero cost' cases in trunc.ll

I thought this was a vector widening side effect, but even before this we had some interesting LV decisions (notably over indvars) being made due to these zero costs.

llvm-svn: 372498

Clang-format: Add Whitesmiths indentation style

Summary:
This patch adds support for the Whitesmiths indentation style to clang-format. It’s an update to a patch submitted in 2015 (D6833), but reworks it to use the newer API.

There are still some issues with this patch, primarily around `switch` and `case` support. The added unit test won’t currently pass because of the remaining issues.

Reviewers: mboehme, MyDeveloperDay, djasper

Reviewed By: MyDeveloperDay

Subscribers: krasimir, MyDeveloperDay, echristo, cfe-commits

Patch By: @timwoj (Tim Wojtulewicz)

Tags: #clang

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

llvm-svn: 372497

Move classes into anonymous namespaces. NFC.

llvm-svn: 372495

[X86] Add test memset and memcpy testcases for D67874. NFC

llvm-svn: 372494

Use _WIN32 instead of _MSC_VER

Summary: This way it works better with MinGW.

Subscribers: mstorsjo, lldb-commits

Tags: #lldb

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

llvm-svn: 372493

NFC: Change ObjCQualified*TypesAreCompatible to take
ObjCObjectPointerType arguments.

All callers already had one, just creating a QualType to pass, after
which the function cast it right back.

llvm-svn: 372492

[InstSimplify] simplifyUnsignedRangeCheck(): X >= Y && Y == 0  -->  Y == 0

https://rise4fun.com/Alive/v9Y4

llvm-svn: 372491

[InstSimplify][NFC] Reorganize simplifyUnsignedRangeCheck() to emphasize and/or symmetry

Only a single `X >= Y && Y == 0  -->  Y == 0` fold appears to be missing.

llvm-svn: 372490

[NFC][InstSimplify] Add exhaustive test coverage for simplifyUnsignedRangeCheck().

One case is not handled.

llvm-svn: 372489

[Docs] Updates sidebar links

Adds sidebar links to mailing lists, IRC, and meetups and social events.

llvm-svn: 372488

[Docs] Adds new page for Getting Involved articles

Adds a new page for existing Getting Involved, Development Process, and Community Proposals articles. Also moves Mailing Lists, Meetups and social events, and IRC sections.

llvm-svn: 372487

[LLDB] Cast -1 (as invalid socket) to the socket type before comparing

This silences warnings about comparison of integers between unsigned
long long (which is what the Windows SOCKET type is) and signed int
when building in MinGW mode.

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

llvm-svn: 372486

[LLDB] Use SetErrorStringWithFormatv for cases that use LLVM style format strings

SetErrorStringWithFormat only supports normal printf style format
strings.

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

llvm-svn: 372485

[LLDB] Use LLVM_FALLTHROUGH instead of a custom comment

This fixes a warning when built with Clang in MinGW mode.

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

llvm-svn: 372484

[LLDB] Check for the GCC/MinGW compatible arch defines for windows, in addition to MSVC defines

This matches how it is done in all other similar ifdefs throughout
lldb.

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

llvm-svn: 372483

[LLDB] Fix compilation for MinGW, remove redundant class name on inline member

This fixes build errors like these:

NativeRegisterContextWindows.h:22:33: error: extra qualification on member 'NativeRegisterContextWindows'
  NativeRegisterContextWindows::NativeRegisterContextWindows(
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^

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

llvm-svn: 372482

[CodeView] Add pragma push/pop_macro for ARM64_FPSR to enum header

This fixes (one aspect of) compilation of LLDB with MSVC for ARM64.

LLDB source files include intrin.h, and the MSVC intrin.h transitively
includes arm64intr.h, which has an ARM64_FPSR define, which clashes
with the enum declaration.

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

llvm-svn: 372481

SROA: Check Total Bits of vector type

While Promoting alloca instruction of Vector Type,
Check total size in bits of its slices too.
If they don't match, don't promote the alloca instruction.

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

llvm-svn: 372480

Test mail. NFC.

Testing commit acces. NFC.

llvm-svn: 372479

Recommit [SampleFDO] Expose an interface to return the size of a section
or the size of the profile for profile in ExtBinary format.

Fix a test failure on Mac.

[SampleFDO] Expose an interface to return the size of a section or the
size of the profile for profile in ExtBinary format.

Sometimes we want to limit the size of the profile by stripping some functions
with low sample count or by stripping some function names with small text size
from profile symbol list. That requires the profile reader to have the
interfaces returning the size of a section or the size of total profile. The
patch add those interfaces.

At the same time, add some dump facility to show the size of each section.

Differential revision: https://reviews.llvm.org/D67726

llvm-svn: 372478

[Attributor] Implement "norecurse" function attribute deduction

Summary:
This patch introduces `norecurse` function attribute deduction.

`norecurse` will be deduced if the following conditions hold:
* The size of SCC in which the function belongs equals to 1.
* The function doesn't have self-recursion.
* We have `norecurse` for all call site.

To avoid a large change, SCC is calculated using scc_iterator in InfoCache initialization for now.

Reviewers: jdoerfert, sstefan1

Reviewed By: jdoerfert

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 372475

[Support] Add a DataExtractor constructor that takes ArrayRef<uint8_t>

The new constructor can simplify some llvm-readobj call sites.

Reviewed By: grimar, dblaikie

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

llvm-svn: 372473

[Docs] Bug fix for document not included in toctree

Fixes 'document not included in toctree' bug for FAQ and Lexicon topics.

llvm-svn: 372470

[Docs] Updates sidebar links

Adds additional links to sidebar. Also removes Glossary and FAQ from LLVM Design & Overview section. (These links now reside on the sidebar.)

llvm-svn: 372469

[NFC][X86] Adjust check prefixes in bmi.ll (PR43381)

llvm-svn: 372468

[AArch64][GlobalISel] Implement selection for G_SHL of <2 x i64>

Simple continuation of existing selection support.

llvm-svn: 372467

[AArch64][GlobalISel] Selection support for G_ASHR of <2 x s64>

Just add an extra case to the existing selection logic.

llvm-svn: 372466

[AArch64][GlobalISel] Make <4 x s32> G_ASHR and G_LSHR legal.

llvm-svn: 372465

Revert "[SampleFDO] Expose an interface to return the size of a section or the size"

This reverts commit f118852046a1d255ed8c65c6b5db320e8cea53a0.

Broke the macOS build/greendragon bots.

llvm-svn: 372464

[MachinePipeliner] Improve the TargetInstrInfo API analyzeLoop/reduceLoopCount

Recommit: fix asan errors.

The way MachinePipeliner uses these target hooks is stateful - we reduce trip
count by one per call to reduceLoopCount. It's a little overfit for hardware
loops, where we don't have to worry about stitching a loop induction variable
across prologs and epilogs (the induction variable is implicit).

This patch introduces a new API:

  /// Analyze loop L, which must be a single-basic-block loop, and if the
  /// conditions can be understood enough produce a PipelinerLoopInfo object.
  virtual std::unique_ptr<PipelinerLoopInfo>
  analyzeLoopForPipelining(MachineBasicBlock *LoopBB) const;

The return value is expected to be an implementation of the abstract class:

  /// Object returned by analyzeLoopForPipelining. Allows software pipelining
  /// implementations to query attributes of the loop being pipelined.
  class PipelinerLoopInfo {
  public:
    virtual ~PipelinerLoopInfo();
    /// Return true if the given instruction should not be pipelined and should
    /// be ignored. An example could be a loop comparison, or induction variable
    /// update with no users being pipelined.
    virtual bool shouldIgnoreForPipelining(const MachineInstr *MI) const = 0;

    /// Create a condition to determine if the trip count of the loop is greater
    /// than TC.
    ///
    /// If the trip count is statically known to be greater than TC, return
    /// true. If the trip count is statically known to be not greater than TC,
    /// return false. Otherwise return nullopt and fill out Cond with the test
    /// condition.
    virtual Optional<bool>
    createTripCountGreaterCondition(int TC, MachineBasicBlock &MBB,
                                 SmallVectorImpl<MachineOperand> &Cond) = 0;

    /// Modify the loop such that the trip count is
    /// OriginalTC + TripCountAdjust.
    virtual void adjustTripCount(int TripCountAdjust) = 0;

    /// Called when the loop's preheader has been modified to NewPreheader.
    virtual void setPreheader(MachineBasicBlock *NewPreheader) = 0;

    /// Called when the loop is being removed.
    virtual void disposed() = 0;
  };

The Pipeliner (ModuloSchedule.cpp) can use this object to modify the loop while
allowing the target to hold its own state across all calls. This API, in
particular the disjunction of creating a trip count check condition and
adjusting the loop, improves the code quality in ModuloSchedule.cpp.

llvm-svn: 372463

Attempt to fix a windows buildbot failure

llvm-svn: 372462

Add __lsan::ScopedInterceptorDisabler for strerror(3)

Summary:
strerror(3) on NetBSD uses internally TSD with a destructor that is never
fired for exit(3). It's correctly called for pthread_exit(3) scenarios.

This is a case when a leak on exit(3) is expected, unavoidable and harmless.

Reviewers: joerg, vitalybuka, dvyukov, mgorny

Reviewed By: vitalybuka

Subscribers: dmgreen, kristof.beyls, jfb, llvm-commits, #sanitizers

Tags: #sanitizers, #llvm

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

llvm-svn: 372461

Avoid memory leak in ASan test

Summary:
Add missing free(3) for the malloc(3) call.

Detected on NetBSD with LSan.

Reviewers: joerg, mgorny, vitalybuka, dvyukov

Reviewed By: vitalybuka

Subscribers: llvm-commits, #sanitizers

Tags: #sanitizers, #llvm

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

llvm-svn: 372460

Stop tracking atexit/__cxa_atexit/pthread_atfork allocations in LSan/NetBSD

Summary:
The atexit(3) and __cxa_atexit() calls allocate internally memory and free on exit,
after executing all callback. This causes false positives as DoLeakCheck() is called
from the atexit handler. In the LSan/ASan tests there are strict checks triggering
false positives here.

Intercept all atexit(3) and __cxa_atexit() calls and disable LSan when calling the
real functions.

Stop tracing allocations in pthread_atfork(3) funtions, as there are performed
internal allocations that are not freed for the time of running StopTheWorld()
code. This avoids false-positives.

The same changes have to be replicated in the ASan and LSan runtime.

Non-NetBSD OSs are not tested and this code is restricted to NetBSD only.

Reviewers: dvyukov, joerg, mgorny, vitalybuka, eugenis

Reviewed By: vitalybuka

Subscribers: jfb, llvm-commits, #sanitizers

Tags: #sanitizers, #llvm

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

llvm-svn: 372459

[X86] Use sse_load_f32/f64 and timm in patterns for memory form of vgetmantss/sd.

Previously we only matched scalar_to_vector and scalar load, but
we should be able to narrow a vector load or match vzload.

Also need to match TargetConstant instead of Constant. The register
patterns were previously updated, but not the memory patterns.

llvm-svn: 372458

[X86] Add test case to show failure to fold load with getmantss due to isel pattern looking for Constant instead of TargetConstant

The intrinsic has an immarg so its gets created with a TargetConstant
instead of a Constant after r372338. The isel pattern was only
updated for the register form, but not the memory form.

llvm-svn: 372457

[Clang Interpreter] Fixed Bug 43362, build failure on GCC

free() was not directly included in InterpStack.cpp, added include now.

llvm-svn: 372455

Fix bad APInt compare.

APInt comparison require both to have the same bitwidth.  Since only the value
is needed, use the compare function APInt::isSameValue instead.

llvm-svn: 372454

Merge and improve code that detects same value in comparisons.

-Wtautological-overlap-compare and self-comparison from -Wtautological-compare
relay on detecting the same operand in different locations.  Previously, each
warning had it's own operand checker.  Now, both are merged together into
one function that each can call.  The function also now looks through member
access and array accesses.

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

llvm-svn: 372453

Revert assertion added by r372394

The assertion added by r372394 causes CUDA test in test-suite to assert.

The assertion was not there originally, so revert it.

llvm-svn: 372452

avr targetinfo: remove unneeded dep on MC

llvm-svn: 372451

AMDGPU/GlobalISel: Allow selection of scalar min/max

I believe all of the uniform/divergent pattern predicates are
redundant and can be removed. The uniformity bit already influences
the register class, and nothhing has broken when I've removed this and
others.

llvm-svn: 372450

LiveIntervals: Add missing operator!= for segments

llvm-svn: 372449

Improve -Wtautological-overlap-compare

Allow this warning to detect a larger number of constant values, including
negative numbers, and handle non-int types better.

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

llvm-svn: 372448

Support for 64-bit PC-relative relocations for X86_64

ELF files generated for X86_64 targets may contain 64-bit PC-relative
relocations. For instance, an exception handler table entry contains the start
of exception-throwing frame relative to the start of exception handler. As these
two labels belong to different sections, their difference and so the relocation
is 64-bit.

An attempt to parse such file, i.e. in DWARFContext::create, results in "failed
to compute relocation" error.

This fix adds support for such relocations to RelocationResolver.cpp.

Reviewed By: MaskRay

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

Patch by Oleg Pliss (Oleg.Pliss@azul.com)

llvm-svn: 372447

gn build: Merge r372445

llvm-svn: 372446

[clang-tidy] Add check for classes missing -hash ⚠️

Summary:
Apple documentation states that:
"If two objects are equal, they must have the same hash value. This last
point is particularly important if you define isEqual: in a subclass and
intend to put instances of that subclass into a collection. Make sure
you also define hash in your subclass."
https://developer.apple.com/documentation/objectivec/1418956-nsobject/1418795-isequal?language=objc

In many or all versions of libobjc, -[NSObject isEqual:] is a pointer
equality check and -[NSObject hash] returns the messaged object's
pointer. A relatively common form of developer error is for a developer to
override -isEqual: in a subclass without overriding -hash to ensure that
hashes are equal for objects that are equal.

It is assumed that an override of -isEqual: is a strong signal for
changing the object's equality operator to something other than pointer
equality which implies that a missing override of -hash could result in
distinct objects being equal but having distinct hashes because they are
independent instances. This added check flags classes that override
-isEqual: but inherit NSObject's implementation of -hash to warn of the
potential for unexpected behavior.

The proper implementation of -hash is the responsibility of the
developer and the check will only verify that the developer made an
effort to properly implement -hash. Developers can set up unit tests
to verify that their implementation of -hash is appropriate.

Test Notes:
Ran check-clang-tools.

Reviewers: aaron.ballman, benhamilton

Reviewed By: aaron.ballman

Subscribers: Eugene.Zelenko, mgorny, xazax.hun, cfe-commits

Tags: #clang

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

llvm-svn: 372445

[clang-scan-deps] strip the --serialize-diagnostics argument

This ensures that clang-scan-deps won't write out diagnostics when
scanning dependencies.

llvm-svn: 372444

[GlobalISel] Defer setting HasCalls on MachineFrameInfo to selection time.

We currently always set the HasCalls on MFI during translation and legalization if
we're handling a call or legalizing to a libcall. However, if that call is later
optimized to a tail call then we don't need the flag. The flag being set to true
causes frame lowering to always save and restore FP/LR, which adds unnecessary code.

This change does the same thing as SelectionDAG and ports over some code that scans
instructions after selection, using TargetInstrInfo to determine if target opcodes
are known calls.

Code size geomean improvements on CTMark:
 -O0 : 0.1%
 -Os : 0.3%

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

llvm-svn: 372443