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

Revert "[DwarfDebug] Support emitting function-local declaration for a lexical block" & dependent patches

This patch causes invalid DWARF to be generated in some cases of LTO +
Split DWARF - follow-up on the original review thread (D113741) contains
further detail and test cases.

This reverts commit 75b622a7.
This reverts commit b6ccca21.
This reverts commit 514d3744.

This change enables divergence-driven instruction selection for the build_vector DAG nodes.
It also enables packed i16 instructions for GFX9.

Reviewed By: rampitec

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

These headers have stabilized; we don't expect anyone to be
blindly clang-formatting them anymore.
Leave the comments in `__format/*.h` for Mark to remove at his leisure.

Currently the singleton `config` is assigned by `config = make<Configuration>()`
and (if `canExitEarly` is false) destroyed by `lld::freeArena`.

`make<Configuration>` allocates a stab with `malloc(4096)`. This both wastes
memory and bloats the executable (every type instantiates `BumpPtrAllocator`
which costs more than 1KiB code on x86-64).

(No need to worry about `clang::no_destroy`. Regular invocations (`canExitEarly`
is true) call `_Exit` via llvm::sys::Process::ExitNoCleanup.)

Reviewed By: lichray

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

Reviewed By: michaelrj, lntue

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

When looking at building the generator for regalloc, we realized we'd
need quite a bit of custom logic, and that perhaps it'd be easier to
just have each usecase (each kind of mlgo policy) have it's own
stand-alone test generator.

This patch just consolidates the old `config.py` and
`generate_mock_model.py` into one file, and does away with
subdirectories under Analysis/models.

Change to comments only; NFC.

```
ClangTidyDiagnosticConsumer.h:245:6: warning: '\param' command used in a
comment that is not attached to a function declaration [-Wdocumentation]
```

See this build for an example:
https://lab.llvm.org/buildbot/#/builders/109/builds/27293/steps/5/logs/warnings__702_

Fix handling of alloc-like instructions in isGuaranteedLoopInvariant(). It was not valid when the 'KillingDef' was outside of the loop, while the 'CurrentDef' was inside the loop. In that case, the 'KillingDef' only overwrites the definition from the last iteration of the loop, and not the ones of all iterations. Therefor it does not make the 'CurrentDef' to be dead, and must not remove it.

Fixing issue : https://github.com/llvm/llvm-project/issues/52774

Reviewed by: Florian Hahn

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

Remaining var that had 'inlining' in name, despite being general-purpose

HVX does not have load/store instructions for vector predicates (i.e. bool
vectors). Because of that, vector predicates need to be converted to another
type before being stored, and the most convenient representation is an HVX
vector.
As a consequence, in C/C++, source-level builtins that either take or
produce vector predicates take or return regular vectors instead. On the
other hand, the corresponding LLVM intrinsics do have boolean types that,
and so a conversion of the operand or the return value was necessary.
This conversion would happen inside clang's codegen, but was somewhat
fragile.

This patch changes the strategy: a builtin that takes a vector predicate
now really expects a vector predicate. Since such a predicate cannot be
provided via a variable, this builtin must be composed with other builtins
that either convert vector to a predicate (V6_vandvrt) or predicate to a
vector (V6_vandqrt).

For users using builtins defined in hvx_hexagon_protos.h there is no impact:
the conversions were added to that file. Other users will need to insert
- __builtin_HEXAGON_V6_vandvrt[_128B](V, -1) to convert vector V to a
  vector predicate, or
- __builtin_HEXAGON_V6_vandqrt[_128B](Q, -1) to convert vector predicate Q
  to a vector.

Builtins __builtin_HEXAGON_V6_vmaskedstore.* are a temporary exception to
that, but they are deprecated and should not be used anyway. In the future
they will either follow the same rule, or be removed.

FileOffset is unsigned while getLocWithOffset() requires a signed value.

Several unit test folders were missing from the bazel build, including: Transforms, Conversion, Rewrite

Pre-commiting the test case before the bug fix.

Reviewed by: Florian Hahn

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

I missed two instances of "SetUp" being replaced by "set_up" and
"TearDown" being replaced by "tear_down" when finalizing the formatting
change. This fixes that.

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

Previously, we defined a struct named `RootOrderingCost`, which stored the cost (a pair consisting of the depth of the connector and a tie breaking ID), as well as the connector itself. This created some confusion, because we would sometimes write, e.g., `cost.cost.first` (the first `cost` referring to the struct, the second one referring to the `cost` field, and `first` referring to the depth). In order to address this confusion, here we rename `RootOrderingCost` to `RootOrderingEntry` (keeping the fields and their names as-is).

This clarification exposed non-determinism in the optimal branching algorithm. When choosing the best local parent, we were previuosly only considering its depth (`cost.first`) and not the tie-breaking ID (`cost.second`). This led to non-deterministic choice of the parent when multiple potential parents had the same depth. The solution is to compare both the depth and the tie-breaking ID.

Testing: Rely on existing unit tests. Non-detgerminism is hard to unit-test.

Reviewed By: rriddle, Mogball

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

There is no way to programmatically configure the list of disabled and enabled patterns in the canonicalizer pass, other than the duplicate the whole pass. This patch exposes the `disabledPatterns` and `enabledPatterns` options.

Reviewed By: mehdi_amini

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

Apply the formatting rules that were applied to the libc/src directory
to the libc/test directory, as well as the files in libc/utils that are
included by the tests. This does not include automated enforcement.

Reviewed By: sivachandra, lntue

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

Missed by MSVC

Clang is gaining `auto(x)` support in D113393; sadly there
seems to be no feature-test macro for it. Zhihao is opening
a core issue for that macro.

Use `_LIBCPP_AUTO_CAST` where C++20 specifies we should use `auto(x)`;
stop using `__decay_copy(x)` in those places.
In fact, remove `__decay_copy` entirely. As of C++20, it's purely
a paper specification tool signifying "Return just `x`, but it was
perfect-forwarded, so we understand you're going to have to call
its move-constructor sometimes." I believe there's no reason we'd
ever need to do its operation explicitly in code.

This heisenbugs away a test failure on MinGW; see D112214.

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

Previously, the folding assumed that it always operates on scalar types.

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

Add callback to enable us to test target nodes if they are splat vectors

Added some basic X86ISD::VBROADCAST + X86ISD::VBROADCAST_LOAD handling

This reverts commit 9075009d.

 Failed amdgpu runtime buildbot # 3514

Over in D114631 I turned this debug-info feature on by default, for x86_64
only. I'd previously stripped out the clang cc1 option that controlled it
in 651122fc, unfortunately that turned out to not be completely
effective, and the two things deleted in this patch continued to keep it
off-by-default.  Oooff.

As a follow-up, this patch removes the last few things to do with
ValueTrackingVariableLocations from clang, which was the original purpose
of D114631. In an ideal world, if this patch causes you trouble you'd
revert 3c045070 instead, which was where this behaviour was supposed
to start being the default, although that might not be practical any more.

Just to keep code consistent as `OpenMPAtomicUpdateChecker` is defined
in anonymous namespace.

Reviewed By: ABataev

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

Regenerate test checks to reduce diff for an upcoming patch.

gen_ast_dump_json_test.py adds these lines of whitespace. Precommit
it to avoid spurious diffs in future changes.

Suggest converting `std::string::rfind()` calls to `absl::StartsWith()`
where possible.

As discussed with ldionne. The problem with this static_assert
is that it makes ranges::begin a pitfall for anyone ever to use
inside a constraint or decltype. Many Ranges things, such as ranges::size,
are specified as "Does X if X is well-formed, or else Y if Y is well-formed,
or else `ranges::end(t) - ranges::begin(t)` if that is well-formed, or else..."
And if there's a static_assert hidden inside `ranges::begin(t)`, then you get
a hard error as soon as you ask the question -- even if the answer would have
been "no, that's not well-formed"!

Constraining on `requires { t + 0; }` or `requires { t + N; }` is verboten
because of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103700 . For ranges::begin,
we can just decay to a pointer even in the incomplete-type case. For ranges::end,
we can safely constrain on `sizeof(*t)`. Yes, this means that an array of incomplete
type has a `ranges::begin` but no `ranges::end`... just like an unbounded array of
complete type. This is a valid manifestation of IFNDR.

All of the new libcxx/test/std/ cases are mandatory behavior, as far as I'm aware.
Tests for the IFNDR cases in ranges::begin and ranges::end remain in `libcxx/test/libcxx/`.
The similar tests for ranges::empty and ranges::data were simply wrong, AFAIK.

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

Currently the return address ABI registers s[30:31], which fall in the call
clobbered register range, are added as a live-in on the function entry to
preserve its value when we have calls so that it gets saved and restored
around the calls.

But the DWARF unwind information (CFI) needs to track where the return address
resides in a frame and the above approach makes it difficult to track the
return address when the CFI information is emitted during the frame lowering,
due to the involvment of understanding the control flow.

This patch moves the return address ABI registers s[30:31] into callee saved
registers range and stops adding live-in for return address registers, so that
the CFI machinery will know where the return address resides when CSR
save/restore happen during the frame lowering.

And doing the above poses an issue that now the return instruction uses undefined
register `sgpr30_sgpr31`. This is resolved by hiding the return address register
use by the return instruction through the `SI_RETURN` pseudo instruction, which
doesn't take any input operands, until the `SI_RETURN` pseudo gets lowered to the
`S_SETPC_B64_return` during the `expandPostRAPseudo()`.

As an added benefit, this patch simplifies overall return instruction handling.

Note: The AMDGPU CFI changes are there only in the downstream code and another
version of this patch will be posted for review for the downstream code.

Reviewed By: arsenm

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