See https://github.com/llvm/llvm-project/issues/141

Summary: Forget static keyword for gcov_mutex in https://reviews.llvm.org/D74953 and that causes test failure on mac.

Reviewers: erik.pilkington, vsk

Reviewed By: vsk

Subscribers: vsk, dexonsmith, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

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

This makes sure targets are rebuilt if a file is added or removed.
Reviewer: tstellar
Differential Revision: https://reviews.llvm.org/D74662

Beside being cleaner we can probably reuse that logic elsewhere.

These can come out nondeterministically for two reasons:
- sorting based on ConstStringified pointer values
- different relative speeds of the indexing threads

Making these nondeterministic without incurring performance penalties is
hard, so I just make the test expect them in any order (the order is not
important in this test anyway.

Seems like this code raised some alarm bells as it looks like an ArrayRef
to a temporary initializer list, but it's actually just calling the ArrayRef(T*, T*)
constructor. Let's clarify this and directly call the right ArrayRef constructor here.

Fixes rdar://problem/59176052

Summary:
This is a quality of life change to make it a little nicer to look at, NFC.
This patch makes the RUN and OK lines green and FAILED lines red to match gtest's output.

Reviewers: sivachandra, gchatelet, PaulkaToast

Reviewed By: gchatelet

Subscribers: MaskRay, tschuett, libc-commits

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

Might be able to get rid of X86ISD::SCATTER and some uses of
X86ISD::GATHER. Which require isel to use ISD::SCATTER and
ISD::GATHER as well.

Instead add it when we make the machine nodes during instruction
selections.

This makes this ISD node closer to ISD::MGATHER. Trying to see
if we remove the X86 specific ones.

Summary:
Acts on `BinaryOperator` and `UnaryOperator` and functions the same as `anyOf(hasOperatorName(...), hasOperatorName(...), ...)`

Documentation generation isn't perfect but I feel that the python doc script needs updating for that

Reviewers: aaron.ballman, gribozavr2

Reviewed By: aaron.ballman, gribozavr2

Subscribers: cfe-commits

Tags: #clang

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

Summary: Use move semantics instead of copying for AST Matchers with parameters

Reviewers: aaron.ballman, gribozavr2

Reviewed By: gribozavr2

Subscribers: cfe-commits

Tags: #clang

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

Summary:
I added an `abort()` call to some code and noticed that the test suite was still passing and it just marked my test as "UNSUPPORTED".

It seems the reason for that is that we expect failing tests to print "FAIL:" which doesn't happen when we crash. If we then also
have an unsupported because we skipped some debug information in the output, we just mark the test passing because it is unsupported
on the current platform.

This patch marks any test that has a non-zero exit code as failing even if it doesn't print "FAIL:" (e.g., because it crashed).

Reviewers: labath, JDevlieghere

Reviewed By: labath, JDevlieghere

Subscribers: aprantl, lldb-commits

Tags: #lldb

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

These are technically text files, but the object file layer treats them
as binary, and the relevant tests verify the parsed contents byte for
byte. Git's crlf conversion can make those tests fail. Marking the files
as non-text disables that.

Order of evaluation of the operands of any C++ operator [...] is
unspecified. This patch fixes the issue in Stream::Indent by calling the
function consecutively.

On my Windows setup, TestSettings.py fails because the function prints
the value first, followed by the indentation.

Expected result:
  MY_FILE=this is a file name with spaces.txt

Actual result:
MY_FILE  =this is a file name with spaces.txt

Removes implicit unsigned->Register conversion.

The current set of custom combines are only really useful after
legalization, so move them there. There is a lot of overlap in the
boilerplate here, but I think we do want a pretty different set of
combines before and after legalize. I think we will want a lot of
overlap between the post-legalize and a post-regbankselect combiner.

The aarcht64-ubuntu bot is showing a test failure in TestHandleAbort.py
with this patch.  Adding some logging to that file, it looks like
the saved register context above the trap handler does not have
save state for $pc, but it does have it for $lr on that platform.
I need to fall back to looking for $lr if the $pc cannot be retrieved.
I'll update the patch and re-commit once that's fixed.

This reverts commit edc4f4c9.

This reverts commit 082f1a3b.

MachineVerifier still takes 45-50% of total compile time with
-verify-machineinstrs, with calcRegsPassed dataflow taking ~50-60% of
MachineVerifier.

The majority of that time is spent in BBInfo::addPassed, mostly within
DenseSet implementing the sets the dataflow is operating over.

In particular, 1/4 of that DenseSet time is spent just iterating over it
(operator++), 40-50% on insertions, and most of the rest in ::count.

Given that, we're implementing custom sets just for this analysis here,
focusing on cheap insertions and O(n) iteration time (as opposed to
O(U), where U is the universe).

As it's based _mostly_ on BitVector for sparse and SmallVector for
dense, it may remotely resemble SparseSet. The difference is, our
solution is a lot less clever, doesn't have constant time `clear` that
we won't use anyway as reusing these sets across analyses is cumbersome,
and thus more space efficient and safer (got a resizable Universe and a
fallback to DenseSet for sparse if it gets too big).

With this patch MachineVerifier gets ~15-20% faster, its contribution to
total compile time drops from 45-50% to ~35%, while contribution of
calcRegsPassed to MachineVerifier drops from 50-60% to ~35% as well.

calcRegsPassed itself gets another 2x faster here.

All measured on a large suite of shaders targeting a number of GPUs.

Reviewers: bogner, stoklund, rudkx, qcolombet

Reviewed By: rudkx

Tags: #llvm

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

Summary:
Clang's "asm goto" feature didn't initially support outputs constraints. That
was the same behavior as gcc's implementation. The decision by gcc not to
support outputs was based on a restriction in their IR regarding terminators.
LLVM doesn't restrict terminators from returning values (e.g. 'invoke'), so
it made sense to support this feature.

Output values are valid only on the 'fallthrough' path. If an output value's used
on an indirect branch, then it's 'poisoned'.

In theory, outputs *could* be valid on the 'indirect' paths, but it's very
difficult to guarantee that the original semantics would be retained. E.g.
because indirect labels could be used as data, we wouldn't be able to split
critical edges in situations where two 'callbr' instructions have the same
indirect label, because the indirect branch's destination would no longer be
the same.

Reviewers: jyknight, nickdesaulniers, hfinkel

Reviewed By: jyknight, nickdesaulniers

Subscribers: MaskRay, rsmith, hiraditya, llvm-commits, cfe-commits, craig.topper, rnk

Tags: #clang, #llvm

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

Summary:
Terminators in LLVM aren't prohibited from returning values. This means that
the "callbr" instruction, which is used for "asm goto", can support "asm goto
with outputs."

This patch removes all restrictions against "callbr" returning values. The
heavy lifting is done by the code generator. The "INLINEASM_BR" instruction's
a terminator, and the code generator doesn't allow non-terminator instructions
after a terminator. In order to correctly model the feature, we need to copy
outputs from "INLINEASM_BR" into virtual registers. Of course, those copies
aren't terminators.

To get around this issue, we split the block containing the "INLINEASM_BR"
right before the "COPY" instructions. This results in two cheats:

  - Any physical registers defined by "INLINEASM_BR" need to be marked as
    live-in into the block with the "COPY" instructions. This violates an
    assumption that physical registers aren't marked as "live-in" until after
    register allocation. But it seems as if the live-in information only
    needs to be correct after register allocation. So we're able to get away
    with this.

  - The indirect branches from the "INLINEASM_BR" are moved to the "COPY"
    block. This is to satisfy PHI nodes.

I've been told that MLIR can support this handily, but until we're able to
use it, we'll have to stick with the above.

Reviewers: jyknight, nickdesaulniers, hfinkel, MaskRay, lattner

Reviewed By: nickdesaulniers, MaskRay, lattner

Subscribers: rriddle, qcolombet, jdoerfert, MatzeB, echristo, MaskRay, xbolva00, aaron.ballman, cfe-commits, JonChesterfield, hiraditya, llvm-commits, rnk, craig.topper

Tags: #llvm, #clang

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

macro section dumping.

Summary: Previously macinfo infrastructure was using functions
names that were ambiguous i.e `getMacro/getMacroDWO` in a sense
of conveying stated intentions. This patch refactored them into more
reasonable `getDebugMacinfo/getDebugMacinfoDWO` names thus making
room for macro implementation.

Reviewers: aprantl, probinson, jini.susan.george, dblaikie

Reviewed By: dblaikie

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

We use some s32 values in VOP3P operands, and won't see any
intervening casts from a 32-bit fneg. Make sure it's really a packed
fneg before folding.

Changes the handling of odd breakdowns, and avoids using
G_EXTRACT/G_INSERT. Pad with undef to a wider size, and unmerge. Also
avoid introducing instructions for the fully undef components.

This is explicitly guaranteed in ARMARM. And it makes reasoning about
vectors easier: we can assume that if a vector operation is legal, the
corresponding scalar operation is also legal.

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

on aarch64-ubuntu - collect a little information about what
is happening on this target before I revert my change; I don't
have access to this target.

This can cause issues with thread safety.

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

Summary:
The RFC for this op is here: https://llvm.discourse.group/t/rfc-add-std-atomic-rmw-op/489

The std.atmomic_rmw op provides a way to support read-modify-write
sequences with data race freedom. It is intended to be used in the lowering
of an upcoming affine.atomic_rmw op which can be used for reductions.

A lowering to LLVM is provided with 2 paths:
- Simple patterns: llvm.atomicrmw
- Everything else: llvm.cmpxchg

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

The former is part of POSIX and requires less heavy headers. They are
practically functionally equivalent.

Depend on the compiler to provide a correct implementation of
max_align_t. If __STDCPP_NEW_ALIGNMENT__ is missing and C++03 mode has
been explicitly enabled, provide a minimal fallback in <new> as
alignment of the largest primitive types.

From https://secure.phabricator.com/book/phabricator/article/arcanist_new_project/:

> An .arcconfig file is a JSON file which you check into your project's root.

I've done some experimentation, and it looks like the subproject
.arcconfigs just get ignored, as the documentation says. Given that
we're fully on the monorepo now, it's safe to remove them.

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

When you run `arc diff`, arc defaults to uploading all the changes you
have against the upstream branch into a single patch. This is almost
never what you want for stacked commits (patch series); you only want to
submit the changes done by the current patch. It's also come up as a
point of confusion in the Phabricator vs. GitHub PRs discussion, for
example. Configure arc to only upload your current patch by default,
which I think is a much more suitable default for LLVM developers.

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

Fix RegisterContextLLDB::InitializeNonZerothFrame so that it
will fetch a FullUnwindPlan instead of falling back to the
architectural default unwind plan -- GetFullUnwindPlan knows
how to spot a jmp 0x0 that results in a fault, which may be
the case when we see a trap handler on the stack.

Fix RegisterContextLLDB::SavedLocationForRegister so that when
the pc value is requested from a trap handler frame, where we
have a complete register context available to us, don't provide
the Return Address register (lr) instead of the pc.  We have
an actual pc value here, and it's pointing to the instruction
that faulted.

Differential revision: https://reviews.llvm.org/D75007
<rdar://problem/59416588>

Summary: Remove `internal::Matcher` and `internal::BindableMatcher` from Result Type when dumping AST Matchers

Reviewers: joerg, gribozavr2, aaron.ballman

Reviewed By: aaron.ballman

Subscribers: cfe-commits

Tags: #clang

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