In error cases it is possible to CLOSE a unit that has not
been successfully connected, so don't crash when the file descriptor
is negative.

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

When closing all open units, don't hold the unit map lock
over the actual close operations; if one of those aborts,
CloseAll() may be called and then deadlock.

Differential Review: https://reviews.llvm.org/D115184

Instead of checking [10:8]. Check for non-zero in 8 and above.

Addresses a post-commit comment from @jrtc27 in D114581.

Print type for VarTemplateDecl in hover.

Reviewed By: sammccall

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

This fixes in a regression introduced by 6eeda06c.

When deducing the return type of nested function calls, only the
return type of the outermost expression should be ignored.

Instead of assuming all contextes nested in a discared statements
are themselves discarded, only assume that in immediate contexts.

Similarly, only consider contextes immediately in an immediate or
discarded statement as being themselves immediate.

Add the calculation of a score, which will be used during ML training. The
score qualifies the quality of a regalloc policy, and is independent of
what we train (currently, just eviction), or the regalloc algo itself.
We can then use scores to guide training (which happens offline), by
formulating a reward based on score variation - the goal being lowering
scores (currently, that reward is percentage reduction relative to
Greedy's heuristic)

Currently, we compute the score by factoring different instruction
counts (loads, stores, etc) with the machine basic block frequency,
regardless of the instructions' provenance - i.e. they could be due to
the regalloc policy or be introduced previously. This is different from
RAGreedy::reportStats, which accummulates the effects of the allocator
alone. We explored this alternative but found (at least currently) that
the more naive alternative introduced here produces better policies. We
do intend to consolidate the two, however, as we are actively
investigating improvements to our reward function, and will likely want
to re-explore scoring just the effects of the allocator.

In either case, we want to decouple score calculation from allocation
algorighm, as we currently evaluate it after a few more passes after
allocation (also, because score calculation should be reusable
regardless of allocation algorithm).

We intentionally accummulate counts independently because it facilitates
per-block reporting, which we found useful for debugging - for instance,
we can easily report the counts indepdently, and then cross-reference
with perf counter measurements.

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

Some users have a need to control attribute extension diagnostics
independent of other extension diagnostics. Consider something like use
of [[nodiscard]] within C++11:
```
[[nodiscard]]
int f();
```
If compiled with -Wc++17-extensions enabled, this will produce warning:
use of the 'nodiscard' attribute is a C++17 extension. This diagnostic
is correct -- using [[nodiscard]] in C++11 mode is a C++17 extension.
And the behavior of __has_cpp_attribute(nodiscard) is also correct --
we support [[nodiscard]] in C++11 mode as a conforming extension. But
this makes use of -Werror or -pedantic-errors` builds more onerous.

This patch adds diagnostic groups for attribute extensions so that
users can selectively disable attribute extension diagnostics. I
believe this is preferable to requiring users to specify additional
flags because it means -Wc++17-extensions continues to be the way we
enable all C++17-related extension diagnostics. It would be quite easy
for someone to use that flag thinking they're protected from some
portability issues without realizing it skipped attribute extensions if
we went the other way.

This addresses PR33518.

the test requires debug build

example of a failed buildbot:
https://lab.llvm.org/buildbot/#/builders/91/builds/211/steps/8/logs/stdio

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

Both the entry and exit blocks of the top-region of a plan must be
VPBasicBlocks. They also must have no predecessors or successors
respectively.

This invariant was broken when splitting a block for sink-after. To fix
the issue, set the exit block of the region *after* sink-after is done.

Reviewed By: Ayal

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

Adding IntrHasSideEffects to @llvm.amdgcn.s.memtime and
@llvm.amdgcn.s.memrealtime means that we can stop pretending they read
and write memory, and similarly for the corresponding pseudo
instructions.

This should stop these intrinsics from being rescheduled past all other
instructions, even ones which don't load or store.

See also https://reviews.llvm.org/D58635.

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

The file name output was not being copied back to the program
from the runtime.

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

This replaces the 'or' from 4b30076f with an 'and'.
We have to guard against propagating undef elements from
vector 'not' values:
https://alive2.llvm.org/ce/z/irMwRc

[RISCV] Replace uses of RISCVOpcode<0b0010011> and RISCVOpcode<0b0011011> with existing named objects. NFC

These are already instantiated with names as OPC_OP_IMM and
OPC_OP_IMM_32.

Reviewed By: frasercrmck

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

These functions are generic utility functions that operates on
affine ops within SCF regions. Moving them to their own files
for a better code structure, instead of mixing with loop
specialization logic.

Reviewed By: nicolasvasilache

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

A new basic block ordering improving existing MachineBlockPlacement.

The algorithm tries to find a layout of nodes (basic blocks) of a given CFG
optimizing jump locality and thus processor I-cache utilization. This is
achieved via increasing the number of fall-through jumps and co-locating
frequently executed nodes together. The name follows the underlying
optimization problem, Extended-TSP, which is a generalization of classical
(maximum) Traveling Salesmen Problem.

The algorithm is a greedy heuristic that works with chains (ordered lists)
of basic blocks. Initially all chains are isolated basic blocks. On every
iteration, we pick a pair of chains whose merging yields the biggest increase
in the ExtTSP value, which models how i-cache "friendly" a specific chain is.
A pair of chains giving the maximum gain is merged into a new chain. The
procedure stops when there is only one chain left, or when merging does not
increase ExtTSP. In the latter case, the remaining chains are sorted by
density in decreasing order.

An important aspect is the way two chains are merged. Unlike earlier
algorithms (e.g., based on the approach of Pettis-Hansen), two
chains, X and Y, are first split into three, X1, X2, and Y. Then we
consider all possible ways of gluing the three chains (e.g., X1YX2, X1X2Y,
X2X1Y, X2YX1, YX1X2, YX2X1) and choose the one producing the largest score.
This improves the quality of the final result (the search space is larger)
while keeping the implementation sufficiently fast.

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

These are the trigrams for queries right now:

- "va" -> {Trigram("va")}
- "va_" -> {} (empty)

This is suboptimal since the resulting query will discard the query information
and return all symbols, some of which will be later be scored expensively
(fuzzy matching score). This is related to
https://github.com/clangd/clangd/issues/39 but does not fix it. Accidentally,
because of that incorrect behavior, when user types "tok::va" there are no
results (the issue is that `tok::kw___builtin_va_arg` does not have "va" token)
but when "tok::va_" is typed, expected result (`tok::kw___builtin_va_arg`)
shows up by accident. This is because the dex query transformer will only
lookup symbols within the `tok::` namespace. There won't be many, so the
returned results will contain symbol we need; this symbol will be filtered out
by the expensive checks and that will be displayed in the editor.

Reviewed By: sammccall

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

The fields output when using --output-style=JSON has changed but the
guide wasn't updated. This change fixes up the example.

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

The test already checks the full IR. To make updating easier,
auto-generate the check lines.

The Coding Guidelines specify that the ending brace of a
namespace shall have a comment like:

}  // end namespace clang

However the majority of the code uses a different style:

}  // namespace clang

Indeed:

$ git grep '// end' | wc -l
6724
$ git grep '// namespace' | wc -l
14348

Besides, this is the style enforced automatically by clang-format,
via the FixNamespaceComments option.

Having inconsistencies between the Coding Guidelines and the
code/tooling creates confusion, can lead to bikeshedding during
reviews and overall delays merging code. Therefore, update the
guidelines to reflect current usage. Updating legacy code to the
new standard should be done in a separate patch, if wanted.

Reviewed By: jyknight

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

The test was flaky because it was trying to read from the (redirected)
stdout file before the data was been flushed to it. This would not be a
problem for a "normal" debug session, but since here the emulator and
the target binary coexist in the same process (and this is true both for
real qemu and our fake implementation), there
is a window of time between the stub returning an exit packet (which is
the event that the test is waiting for) and the process really exiting
(which is when the normal flushing happens).

This patch adds an explicit flush to work around this. Theoretically,
it's possible that real code could run into this issue as well, but such
a use case is not very likely. If we wanted to fix this for real, we
could add some code which waits for the host process to terminate (in
addition to receiving the termination packet), but this is somewhat
complicated by the fact that this code lives in the gdb-remote process
plugin.

This setting allows the user to pass additional arguments to the qemu instance.
While we may want to introduce dedicated settings for the most common qemu
arguments (-cpu, for one), having this setting allows us to avoid creating a
setting for every possible argument.

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

[mlir][Linalg] NFC - Extend the TilingInterface to allow better composition with out-of-tree dialects.

Reviewed By: gysit

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

MIPS I, II, and III have delay slots for floating point
comparisons and floating point register transfers (mtc1, mfc1).
Currently, these are not taken into account and thus broken code
may be generated on these targets. This patch inserts nops
as necessary, while attempting to leave the current instruction
if it is safe to stay.

The tests in this patch were updated by @sajattack

Patch by @overdrivenpotato (Marko Mijalkovic <marko.mijalkovic97@gmail.com>)

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

This passes bufferizes FuncOp bodies, but not FuncOp boundaries.

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

In 6c75ab5f, Clang deprecated _ExtInt in favor of _BitInt, which
made this test fail. This patch disables the test on older compilers
and uses the new _BitInt type instead.

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

There are not a lot of bug reports for this feature, so let's mark it
stable.

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

The patch adds LIT tests for SULD, SUST, TEX and TLD4 instructions as
a follow up for D112232. There are a number of FIXME marks that
highlight possible bugs or missed instruction variants.

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

This change implements intrinsics for table.grow, table.fill,
table.size, and table.copy.

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

Restrict duplicate FP_EXTEND/FP_TRUNC -> LOAD/STORE DAG combines to only
larger than NEON types, as these are the ones for which there is custom
lowering.

Update tests so that they go through memory to improve validation.

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

This test is either very slow or loops forever on 32 bit Arm.

One of a few tests causing timeouts on our buildbots:
https://lab.llvm.org/buildbot/#/builders/190/builds/513