This tries to improve adoption of noisy warnings in existing codebases.
Hints have a lot less visual clutter in most of the editors, and DiagnosticTags
already imply a custom decorations per LSP.

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

This commit changes the LLVM IR import to use UnkownLoc for missing
debug locations. This change ensures that we do not accidentially
introduce faulty locations that can influence debugging post export.

This behavior change is not applied to locations of global metadata
operations, as their location will not be exported.

Reviewed By: gysit

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

This changes the costmodelling of the vecreduce.min/max nodes to use the costs
of the relevant min/max intrinsics instead of expanding them to compare and
selects. The getMinMaxReductionCost have changed to take a Opcode for the
relevant intrinsic, dropping the IsUnsigned and CondTy parameters as they are
no longer needed.

A follow up patch will add some basic fminimum/fmaximum costmodelling.

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

GCNHazardRecognizer::fixVcmpxExecWARHazard() mitigates a specific hazard
by inserting a wait on sa_sdst==0 if such a wait isn't already present.
Unfortunately, the check for an existing wait incorrectly checks for one
that doesn't actually care about sa_sdst itself, but requires that no
other counters are waited for.

Once the check is performed correctly, a lit test needs to be updated,
since it is currently testing for the incorrect behaviour.

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

This is a follow-up to D153672 which removed the old debug mode and
moved many of those checks to the regular asserts mode.

The tree invariant check is too expensive for the regular asserts mode,
making element removal O(n) instead of O(log n), so disable it until
there is a new debug assert category it can be put in.

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

Next step of the preparatory refactoring for the upcoming support of new
new range check form to parse.

This change isolates logic of 'IV vs Limit' range check parsing to
simplify adding parsers for new range checks forms.

Reviewed By: skatkov
Differential Revision: https://reviews.llvm.org/D154160

This reverts commit 2fd614ef.

Commit caused failures on the following two build bots:
  http://45.33.8.238/win/80815/step_7.txt
  https://lab.llvm.org/buildbot/#/builders/139/builds/44269

Next step of the preparatory refactoring for the upcoming support of
new range check form to parse.

Previous one: https://reviews.llvm.org/D154156

With this change we avoid meaningless parsing after realizing that Index
is not AddRec

Reviewed By: skatkov
Differential Revision: https://reviews.llvm.org/D154158

Regenerate checks to avoid unnecessary changes in D154264.

Summary:
This code used `LIBOMPTARGET_DEBUG` which is not the macro name, but the
environment variable. This caused this portion to always be disabled. In
the long run we should aim for this to always be availible as it's
useful for other diagnostic message.

This op needs special handling because the allocation for the masked op must be placed outside of the mask op.

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

Until now, only `tensor.pad` ops could be bufferized to an allocation. This revision adds support for all bufferizable ops that do not already bufferize to an allocation. (Those still need special handling.)

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

It turns out this didn't need to be a template at all.

Likewise, change callers to they're non-template functions.

Also, correct / clarify some comments in RecordOps.h.

This is in response to post-commit comments on https://reviews.llvm.org/D153006.

Reviewed By: gribozavr2

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

The `bufferize_to_allocation` transform op now operates on payload ops, not payload values. Only ops can be bufferized, not values.

Also remove the `replacement` result from the transform op.

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

To keep the message short and consistent with clangd, and the diagnostics are
attached to the #include line, users have enough context to understand the whole #include.

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

The doc comment referred to a boolean parameter that has since been
replaced with an ISD::CondCode.

"transform.structured.pad" now returns all `tensor::PadOp` in addition to the padded ops.

Also add a test case that shows how to force an allocation for "tensor.pad" ops with a custom memory space.

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

`getConstantIntValue` extracts constant values from all constant-like ops, not just `arith::ConstantIndexOp`.

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

The ongoing migration to strict handling of value
categories (see https://discourse.llvm.org/t/70086) will change the way we
handle fields of reference type, and I want to put a test in place that makes
sure we continue to handle this special case correctly.

Depends On D154420

Reviewed By: gribozavr2, xazax.hun

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

The newly added test fails without the other changes in this patch.

Reviewed By: sammccall, gribozavr2

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

This consolidates where this kind of implementations lives and
refactor the code to have more code sharing.

NFC

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

SIInsertWaitcnts inserts waitcnt instructions to resolve data
dependencies. The GFX10+ vscnt (VMEM store count) counter is never used
in this way. It is only used to resolve memory dependencies, and that is
handled by SIMemoryLegalizer. Hence there is no need to conservatively
wait for vscnt to be 0 on function entry and before returns.

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

This patch simplifies line table generation. It removes global
array of all units ranges(RangesTy &getValidAddressRanges()).
The comment says that global array of all units ranges is necessary
to handle corner cases inside line table rows. Removing that
special handling shows that its current usage is handling of
"end of range case" which is already handled correctly
(without special handling). .debug_line tables for clang binary
built with and without this patch are equal.

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

In `clang-scan-deps` contexts, the number of interesting identifiers in PCM files is fairly low (only macros), while the number of identifiers in the importing instance is high (builtins). Marking the whole identifier table out-of-date triggers lots of benign and expensive calls to `ASTReader::updateOutOfDateIdentifiers()`. (That unfortunately happens even for unused identifiers due to `SemaRef.IdResolver.begin(II)` line in `ASTWriter::WriteASTCore()`.)

This patch makes the main code path more similar to C++ modules, where the PCM files have `INTERESTING_IDENTIFIERS` section which lists identifiers that get created in the identifier table of the importing instance and marked as out-of-date. The only difference is that the main code path doesn't *create* identifiers in the table and relies on the importing instance calling `ASTReader::get()` when creating new identifier on-demand. It only marks existing identifiers as out-of-date.

This speeds up `clang-scan-deps` by 5-10%.

Reviewed By: Bigcheese, benlangmuir

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

Move the logic added in 3a57152d to normalizeForPostIncUse to catch
additional un-invertable cases. This fixes another mis-compile pointed
out by @peixin in D153004.

Was added in <https://reviews.llvm.org/D63293>, but never used.

Reviewed By: foad

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

getBroadcastInstrs is only used in VPTransformState::get. Move it closer
to use to reduce unnecessary interaction with ILV object.

This is the first step in untangling the two current jobs of BoolValue.

=== Desired end-state: ===

- BoolValue will model C++ booleans e.g. held in StorageLocations.
  this includes describing uncertainty (e.g. "top" is a Value concern)
- Formula describes analysis-level assertions in terms of SAT atoms.

These can still be linked together: a BoolValue may have a corresponding
SAT atom which is constrained by formulas.

=== Done in this patch: ===

BoolValue is left intact, Formula is just the input type to the
SAT solver, and we build formulas as needed to invoke the solver.

=== Incidental changes to debug string printing: ===

- variables renamed from B0 etc to V0 etc
  B0 collides with the names of basic blocks, which is confusing when
  debugging flow conditions.
- debug printing of formulas (Formula and Atom) uses operator<<
  rather than debugString(), so works with gtest.
  Therefore moved out of DebugSupport.h
- Did the same to Solver::Result, and some helper changes to SolverTest,
  so that we get useful messages on unit test failures
- formulas are now printed as infix expressions on one line, rather than
  wrapped/indented S-exprs. My experience is that this is easier to scan
  FCs for small examples, and large ones are unreadable either way.
- most of the several debugString() functions for constraints/results
  are unused, so removed them rather than updating tests.
  Inlined the one that was actually used into its callsite.

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

In llvm/test/CodeGen/ARM/large-stack.ll, the C in FileCheck wasn't
uppercased. This wasn't spotted in development as MacOS's HFS+ fs is apparently
often configured case-insensitive.

This test previously ran on QEMU or A64FX both of which can/do have
512 bit SVE by default.

Graviton 3 has 256 bit SVE so the first part of the test failed.

To fix this, probe the supported vector lengths before starting
the test. The first check will use the default vector length and
the rest use either 256 or 128 bit.

Therefore this test will be skipped on a machine with only 128 bit SVE.

Reviewed By: omjavaid

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

During __do_global_dtors_aux glibc sets a flag that is right
next to the global variable. This is done using a store byte.

On QEMU the watchpoints are handled with a finer granularity
than real hardware, so this wasn't a problem. On Graviton 3
(and Mountain Jade, though this test won't run there) watchpoints
look at larger chunks of memory.

This means that the final continue actually stops in  __do_global_dtors_aux
instead of exiting.

We could fix this by padding the global to be away from the flag,
but that is fiddly and it is easier just to remove the watchpoint
before the final continue. We have already verified it worked by that
point.

Reviewed By: omjavaid

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

Running this on Amazon Ubuntu the final backtrace is:
```
(lldb) thread backtrace
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
  * frame #0: 0x0000aaaaaaaa07d0 a.out`func_c at main.c:10:3
    frame #1: 0x0000aaaaaaaa07c4 a.out`func_b at main.c:14:3
    frame #2: 0x0000aaaaaaaa07b4 a.out`func_a at main.c:18:3
    frame #3: 0x0000aaaaaaaa07a4 a.out`main(argc=<unavailable>, argv=<unavailable>) at main.c:22:3
    frame #4: 0x0000fffff7b373fc libc.so.6`___lldb_unnamed_symbol2962 + 108
    frame #5: 0x0000fffff7b374cc libc.so.6`__libc_start_main + 152
    frame #6: 0x0000aaaaaaaa06b0 a.out`_start + 48
```
This causes the test to fail because of the extra ___lldb_unnamed_symbol2962 frame
(an inlined function?).

To fix this, strictly check all the frames in main.c then for the rest
just check we find __libc_start_main and _start in that order regardless
of other frames in between.

Reviewed By: omjavaid

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

Add functions AMDGPU::DepCtr::encodeField*() and AMDGPU::DepCtr::decodeField*()
for each of vm_vsrc, va_vdst and sa_sdst. These are now used in
AMDGPUInsertDelayAlu and GCNHazardRecognizer so as to make working with
S_WAITCNT_DEPCTR operands easier and more readable.

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

We started seeing new failure after D142886. Looks like it enabled new cases and we hit an assert:
assert(Current->getNumDefinedValues() == 1 &&
           "only recipes with a single defined value expected");

 When we do instruction sinking for the first order recurrence we hit an assert if instruction doesn't have single def. In case instruction doesn't produce any new def there is no new users and nothing to sink.

Reviewed By: fhahn

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