Summary:
This patch simplifies 2 aspects in the FileCheckNumericVariable code.

First, setValue() method is turned into a void function since being
called only on undefined variable is an invariant and is now asserted
rather than returned. This remove the assert from the callers.

Second, clearValue() method is also turned into a void function since
the only caller does not check its return value since it may be trying
to clear the value of variable that is already cleared without this
being noteworthy.

Reviewers: jhenderson, chandlerc, jdenny, probinson, grimar, arichardson, rnk

Subscribers: JonChesterfield, rogfer01, hfinkel, kristina, rnk, tra, arichardson, grimar, dblaikie, probinson, llvm-commits, hiraditya

Tags: #llvm

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

llvm-svn: 365249

Now shows the actual annotated template. E.g.,
{annot_template_id (A<int, double>)}

Also a few miscellaneous fixes to visualizers of other types

llvm-svn: 365248

We could VerifyDecl sometimes with a nullptr. It would be nice if we
could get an actual assert here instead of triggering UB.

llvm-svn: 365247

We had a long discussion in D59911 about lldb_assert and what it means.
The result was the assert manifesto on lldb.llvm.org.

> LLDB provides lldb_assert() as a soft alternative to cover the middle
> ground of situations that indicate a recoverable bug in LLDB. In a
> Debug configuration lldb_assert() behaves like assert(). In a Release
> configuration it will print a warning and encourage the user to file a
> bug report, similar to LLVM’s crash handler, and then return
> execution.

However, currently lldb_assert doesn't behave they way it's being
described there: it doesn't abort in a debug/assert build. This patch
fixes that by adding a call to assert() in lldb_assert().

Differential revision: https://reviews.llvm.org/D64267#1571962

llvm-svn: 365246

llvm-svn: 365245

This reverts commit 6bb13da7.

llvm-svn: 365244

Reviewers: teemperor, JDevlieghere

Subscribers: lldb-commits

Tags: #lldb

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

llvm-svn: 365243

Only custom lower uaddo+addcarry or usubo+subcarry chains and leave
mixtures like usubo+addcarry or uaddo+subcarry to the generic
legalizer. Otherwise we run into issues because SystemZ uses
different CC values for carries and borrows.

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

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

llvm-svn: 365242

Add a string attribute instead of directly setting
MachineFunctionInfo. This avoids trying to get the analysis in the
MachineFunctionInfo in a way that doesn't work with the new pass
manager.

This will also avoid re-visiting the call graph for every single
function.

llvm-svn: 365241

Summary:
- Explicitly specify the parent MBB to allow the end iterator to be
  used.

Reviewers: aprantl, MatzeB, craig.topper, qcolombet

Subscribers: arsenm, jvesely, nhaehnle, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 365240

Summary:
After rL364464 the following tests started to fail when
running the clang-doc tests with an ubsan instrumented
build of clang-doc:
    Clang Tools :: clang-doc/single-file-public.cpp
    Extra Tools Unit Tests :: clang-doc/./ClangDocTests/BitcodeTest.emitEnumInfoBitcode
    Extra Tools Unit Tests :: clang-doc/./ClangDocTests/BitcodeTest.emitMethodInfoBitcode
    Extra Tools Unit Tests :: clang-doc/./ClangDocTests/BitcodeTest.emitRecordInfoBitcode
    Extra Tools Unit Tests :: clang-doc/./ClangDocTests/SerializeTest.emitInfoWithCommentBitcode

We need to check that the read value is in range for being
casted to the llvm::bitc::FixedAbbrevIDs enum, before the
cast in ClangDocBitcodeReader::skipUntilRecordOrBlock.

SerializedDiagnosticReader::skipUntilRecordOrBlock was updated
in the same way.

Reviewers: jfb

Reviewed By: jfb

Subscribers: Bigcheese, vsapsai, bruno, ilya-biryukov, dexonsmith, kadircet, cfe-commits

Tags: #clang

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

llvm-svn: 365239

This patch makes swap functions constexpr. Both swap overloads, swap_ranges and iter_swap are updated (with tests).

llvm-svn: 365238

llvm-svn: 365237

Avoids a warning in Release builds.

llvm-svn: 365236

llvm-svn: 365235

The Size either needs to be 0 meaning we aren't folding
a stack reload. Or the stack slot needs to be at least
16 bytes. I've also added a paranoia check ensure the
RCSize is at leat 16 bytes as well. This avoids any
FR32/FR64 surprises, but I think we already filtered
those earlier.

All of our test case have Size as either 0 or 16 and
RCSize == 16. So the Size <= 16 check worked for those
cases.

llvm-svn: 365234

This reverts r365222, which broke the libc++ build bots.

llvm-svn: 365233

The indirect call sequence on PPC requires that the TOC base register be saved
prior to the indirect call and restored after the call since the indirect call
may branch to a global entry point in another DSO which will update the TOC
base. Over the last couple of years, we have improved this to:

- be able to hoist TOC saves from loops (with changes to MachineLICM)
- avoid multiple saves when one dominates the other[s]

However, it is still possible to have multiple TOC saves dynamically in the
execution path if there is no dominance relationship between them.

This patch moves the TOC save to the prologue when one of the TOC saves is in a
block that post-dominates entry (i.e. it cannot be avoided) or if it is in a
block that is hotter than entry.

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

llvm-svn: 365232

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

llvm-svn: 365231

Remove unnecessary computation of mangled SP for ARM64 architecture.

Reviewed By: dvyukov

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

llvm-svn: 365230

For x86_64, since we don't clobber %rsi (2nd argument) anymore, we don't
have to save/restore it.

Reviewed By: dvyukov

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

llvm-svn: 365229

llvm-svn: 365228

llvm-svn: 365227

Change the interface to return an expected, instead of taking a Status
pointer.

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

llvm-svn: 365226

[X86] Update SSE1 MOVLPSrm and MOVHPSrm isel patterns to ensure loads are non-volatile before folding.

These patterns use 128-bit loads, but the instructions only load
64-bits. We shouldn't narrow the load if its volatile.

Fixes another variant of PR42079

llvm-svn: 365225

This was identical to a pattern for MOVPQI2QImr with a bitcast
as an input. But we should be able to turn MOVPQI2QImr into
MOVLPSmr in the execution domain fixup pass so we shouldn't
need this.

llvm-svn: 365224

llvm-svn: 365223

Summary:
Otherwise, when libcxxabi is not an enabled project in the monorepo, we
get a link error because we try to link against non-existent cxxabi_shared.

More generally, we shouldn't change the behavior of the build based on
implicit things like whether a file happens to be at a specific path or
not.

Reviewers: EricWF

Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits

Tags: #libc

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

llvm-svn: 365222

--section-data, --section-relocations and --section-symbols have no
effect for GNU style ouput. This patch changes the docs to point this
out, as it has caught me out on a couple of occasions.

See also https://bugs.llvm.org/show_bug.cgi?id=42522.

llvm-svn: 365221

Summary:
This patch changes expression support to use one instance of
FileCheckNumericVariable per numeric variable rather than one per
variable and per definition. The current system was only necessary for
the last patch of the numeric expression support patch series in order
to handle a line using a variable defined earlier on the same line from
the input text. However this can be dealt more efficiently.

Reviewers: jhenderson, chandlerc, jdenny, probinson, grimar, arichardson, rnk

Subscribers: JonChesterfield, rogfer01, hfinkel, kristina, rnk, tra, arichardson, grimar, dblaikie, probinson, llvm-commits, hiraditya

Tags: #llvm

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

llvm-svn: 365220

Summary:
Diagnosing use of undefined variables takes place in
parseNumericVariableUse() and printSubstitutions() for numeric variables
but only takes place in printSubstitutions() for string variables. The
reason for the split location of diagnostics is that parsing is not
aware of the clearing of variables due to --enable-var-scope and thus
use of variables cleared in this way can only be catched by
printSubstitutions().

Beyond the code level inconsistency, there is also a user facing
inconsistency since diagnostics look different between the two
functions. While the diagnostic in printSubstitutions is more verbose,
doing the diagnostic there allows to diagnose all undefined variables
rather than just the first one and error out.

This patch create dummy variable definition when encountering a use of
undefined variable so that parsing can proceed and be diagnosed by
printSubstitutions() later. Tests that were testing whether parsing
fails in such case are thus modified accordingly.

Reviewers: jhenderson, chandlerc, jdenny, probinson, grimar, arichardson, rnk

Subscribers: JonChesterfield, rogfer01, hfinkel, kristina, rnk, tra, arichardson, grimar, dblaikie, probinson, llvm-commits, hiraditya

Tags: #llvm

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

llvm-svn: 365219

llvm-svn: 365218

Patch by Christudasan Devadasan.

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

llvm-svn: 365217

When looking for uses/defs to add kill flags, the iterator was double
incremented, skipping the first instruction in the bundle. The use
register in the first bundle instruction was then incorrectly killed.
The "First" instruction should be the BUNDLE itself as the proper
reverse iterator endpoint.

llvm-svn: 365216

llvm-svn: 365215

This add simple Q register forms of bitwise not instructions.

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

llvm-svn: 365214

llvm-svn: 365213

llvm-svn: 365212

Summary:
This allows the DPP combiner to kick in more often. For example the
exclusive scan generated by the atomic optimizer for a divergent atomic
add used to look like this:

        v_mov_b32_e32 v3, v1
        v_mov_b32_e32 v5, v1
        v_mov_b32_e32 v6, v1
        v_mov_b32_dpp v3, v2  wave_shr:1 row_mask:0xf bank_mask:0xf
        s_nop 1
        v_add_u32_dpp v4, v3, v3  row_shr:1 row_mask:0xf bank_mask:0xf bound_ctrl:0
        v_mov_b32_dpp v5, v3  row_shr:2 row_mask:0xf bank_mask:0xf
        v_mov_b32_dpp v6, v3  row_shr:3 row_mask:0xf bank_mask:0xf
        v_add3_u32 v3, v4, v5, v6
        v_mov_b32_e32 v4, v1
        s_nop 1
        v_mov_b32_dpp v4, v3  row_shr:4 row_mask:0xf bank_mask:0xe
        v_add_u32_e32 v3, v3, v4
        v_mov_b32_e32 v4, v1
        s_nop 1
        v_mov_b32_dpp v4, v3  row_shr:8 row_mask:0xf bank_mask:0xc
        v_add_u32_e32 v3, v3, v4
        v_mov_b32_e32 v4, v1
        s_nop 1
        v_mov_b32_dpp v4, v3  row_bcast:15 row_mask:0xa bank_mask:0xf
        v_add_u32_e32 v3, v3, v4
        s_nop 1
        v_mov_b32_dpp v1, v3  row_bcast:31 row_mask:0xc bank_mask:0xf
        v_add_u32_e32 v1, v3, v1
        v_add_u32_e32 v1, v2, v1
        v_readlane_b32 s0, v1, 63

But now most of the dpp movs are combined into adds:

        v_mov_b32_e32 v3, v1
        v_mov_b32_e32 v5, v1
        s_nop 0
        v_mov_b32_dpp v3, v2  wave_shr:1 row_mask:0xf bank_mask:0xf
        s_nop 1
        v_add_u32_dpp v4, v3, v3  row_shr:1 row_mask:0xf bank_mask:0xf bound_ctrl:0
        v_mov_b32_dpp v5, v3  row_shr:2 row_mask:0xf bank_mask:0xf
        v_mov_b32_dpp v1, v3  row_shr:3 row_mask:0xf bank_mask:0xf
        v_add3_u32 v1, v4, v5, v1
        s_nop 1
        v_add_u32_dpp v1, v1, v1  row_shr:4 row_mask:0xf bank_mask:0xe
        s_nop 1
        v_add_u32_dpp v1, v1, v1  row_shr:8 row_mask:0xf bank_mask:0xc
        s_nop 1
        v_add_u32_dpp v1, v1, v1  row_bcast:15 row_mask:0xa bank_mask:0xf
        s_nop 1
        v_add_u32_dpp v1, v1, v1  row_bcast:31 row_mask:0xc bank_mask:0xf
        v_add_u32_e32 v1, v2, v1
        v_readlane_b32 s0, v1, 63

Reviewers: arsenm, vpykhtin

Subscribers: kzhuravl, nemanjai, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, kbarton, MaskRay, jfb, llvm-commits

Tags: #llvm

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

llvm-svn: 365211

This case implicitly falls-through, which is fine now as it's at the end of the
function, but it seems like an accident waiting to happen.

llvm-svn: 365210