Further enhance the set of operations that can be handled by the sparse compiler

Reviewed By: bixia

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

Extends handling of list initialization of bounded array parameters.
This adds the missing checks on converting each initializer for both
std::initializer_list and arrays. And extends
CompareImplicitConversionSequence to compares array size, for two
conversions to array type.

As noted in this patch, there's a defect in the std concerning the
partial orderability of conversion sequences.  DR2492 has a suggested
direction that will be simple to add once it (hopefully) is accepted.

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

We generally don't put a comment on the #endif when the #if block is so small
that it's unambiguous what the #endif refers to.

Thanks to Arthur O'Dwyer for fixing up some of the tests.

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

Conversion to the LLVM dialect is being refactored to be more progressive and
is now performed as a series of independent passes converting different
dialects. These passes may produce `unrealized_conversion_cast` operations that
represent pending conversions between built-in and LLVM dialect types.
Historically, a more monolithic Standard-to-LLVM conversion pass did not need
these casts as all operations were converted in one shot. Previous refactorings
have led to the requirement of running the Standard-to-LLVM conversion pass to
clean up `unrealized_conversion_cast`s even though the IR had no standard
operations in it. The pass must have been also run the last among all to-LLVM
passes, in contradiction with the partial conversion logic. Additionally, the
way it was set up could produce invalid operations by removing casts between
LLVM and built-in types even when the consumer did not accept the uncasted
type, or could lead to cryptic ...

Fixed code that exceeds 72-column.

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

Fix extra space print for llvm global op when the 'unamed_addr'
attribute was empty. This led to two spaces being printed in the custom
form between non-whitespace chars. A round trip would add an extra space
to a typical spaced form. NFC.

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

As before we maintain backwards compat with older object files
by also infering the TLS flag based on the name of the segment.

This change is was split out from https://reviews.llvm.org/D108877.

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

Once all the bots are passing with from-scratch configs, we can attempt
to make the from-scratch config the default configuration.

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

The motivating case is an infinite loop shown with a reduced test from:
https://llvm.org/PR51762

To solve this, I'm proposing we delete the most obviously broken part of this code.

The bug example shows a fundamental problem: we ask computeKnownBits if a transform
will be profitable, alter the code by creating new instructions, then rely on
computeKnownBits to return the same answer to actually eliminate instructions.

But there's no guarantee that the results will be the same between the 1st and 2nd
calls. In the infinite loop example, we get different answers, so we add
instructions that conflict with some other transform, and we're stuck.

There's at least one other problem visible in the test diff for
`@zext_or_masked_bit_test_uses`: the code doesn't check uses properly, so we can
end up with extra instructions created.

Last, it's not clear if this set of transforms actually improves analysis or
codegen. I spot-checked a few targets and don't see a clear win:
https://godbolt.org/z/x87EWovso

If we do see a regression from this change, codegen seems like the right place to
add a cmp -> bit-hack fold.

If this is too big of a step, we could limit the computeKnownBits calls by not
passing a context instruction and/or limiting the recursion. I checked that those
would stop the infinite loop for PR51762, but that won't guarantee that some other
example does not fall into the same loop.

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

P0692R1 was implemented in https://reviews.llvm.org/D92024
but the status page was not updated.

It was added after we changed the way the CI jobs are run, in particular
how they are pinned down to Linux instances only. As a result, the job
would sometimes run on Mac machines, which we're trying to keep only for
jobs that absolutely need it due to capacity concerns.

this makes the code slightly more readable.

Reviewed By: eugenis

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

These paths are needed when building with per-target runtime directories.

(It's possible to fix this by manually setting these when invoking
cmake, but one isn't supposed to need to do that.)

Also set LLVM_TOOLS_BINARY_DIR while touching this area (as it's
also unset in this case) even if it isn't specifically needed by the
per-target runtime configuration.

Fixed since previous attempt: Don't check if the runtimes directory
is the root of the CMake invocation; when the main LLVM CMake
build builds runtimes, it does invoke a sub-CMake with this directory
as the root too, just as if manually invoking CMake at the runtimes
directory. Instead check whether LLVM_TOOLS_BINARY_DIR was set and
whether find_package(LLVM) succeeded or not.

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

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

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

This is in preparataion of D108457.

This feature doesn't seem to have any dedicated test. Instead some random tests
(e.g. the bitfield tests) are declaring function-local classes for some reason.
This adds a dedicated test so we can clean up those other tests.

Also add FIXME's for some basic stuff that doesn't work. The first FIXME is a
good beginner bug which just requires prepending the function name (in case we
decide to fix it instead of documenting this behaviour). The second FIXME is
caused by LLDB searching for definitions by name (which also seems to miss the
function name so there is a conflict with the outer type).

Some more things that should be tested (and might not work):
* Local classes with member functions with local classes.
* Classes in different functions with same name.
* Classes with the same name in different TUs with internal linkage functions of
  the same name.
* Empty classes are parsed by the DWARF parser in a fast path, so that requires
  dedicated tests.
* Repeat some of the tested logic for C.

Identified in D109359.

Reviewed By: jansvoboda11

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

Finds base classes and structs whose destructor is neither public and
virtual nor protected and non-virtual.
A base class's destructor should be specified in one of these ways to
prevent undefined behaviour.

Fixes are available for user-declared and implicit destructors that are
either public and non-virtual or protected and virtual.

This check implements C.35 [1] from the CppCoreGuidelines.

Reviewed By: aaron.ballman, njames93

Differential Revision: http://reviews.llvm.org/D102325

  [1]: http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rc-dtor-virtual

As discussed on the ticket, I'm intending to add additional 128->256 patterns when we have test coverage, but this addresses a known crash.

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

This patch fixes register save/restore on expression call to also include SVE registers.

This will fix expression calls like:

re re p1

<Register Value P1 before expression>

p <var-name or function call>

re re p1

<Register Value P1 after expression>

In above example register P1 should remain the same before and after the expression evaluation.

Reviewed By: DavidSpickett

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

OpenMP reductions need a neutral element, so we match some known reduction
kinds (integer add/mul/or/and/xor, float add/mul, integer and float min/max) to
define the neutral element and the atomic version when possible to express
using atomicrmw (everything except float mul). The SCF-to-OpenMP pass becomes a
module pass because it now needs to introduce new symbols for reduction
declarations in the module.

Reviewed By: chelini

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

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

This is necessary for PR51796 where we'll update _mm256_loadu2_m128* to use  _mm256_set_m128*

Allow variable number of directories, as allowed by the
specification. NumberOfRvaAndSize will default to 16 if not specified,
as in the past.

Reviewed by: jhenderson

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

[SimplifyCFG] performBranchToCommonDestFolding(): require block-closed SSA form for bonus instructions (PR51125)

I can't seem to wrap my head around the proper fix here,
we should be fine without this requirement, iff we can form this form,
but the naive attempt (https://reviews.llvm.org/D106317) has failed.
So just to unblock the release, put up a restriction.

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

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

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

Identified in D109359.

https://reviews.llvm.org/D109156 did not properly update the case where
the equivalence symbol appearing in the common statement is the
"base symbol of an equivalence group" (this was the only case that previously
worked ok, and the patch broke it).

Fix this and add a test that actually uses this code path.

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

For sve_fp_3op_p_zds_zx we have zero patterns downstream but the
intrinsic args can be added again if/when the patterns are implemented.

Identified in D109359.

Reviewed By: sdesmalen

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