SymbolAndSignals stores SymbolInfo which stores two std::strings. Then
the values are stored in a llvm::DenseMap<llvm::StringRef, double>. When
the sorting is happening, SymbolAndSignals are swapped and thus because
of small string optimization some strings may become invalid. This
results in incorrect ranking.

This was detected when running new std::sort algorithm against llvm
toolchain. This could have been prevented with running llvm::sort and
EXPENSIVE_CHECKS. Unfortunately, no sanitizer yelled.

I don't have commit rights, kutdanila@yandex.ru Danila Kutenin

Reviewed By: bkramer

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

This commit rewrites most existing unittests involving FlatAffineConstraints
to use the parsing utility. This helps to make the tests more understandable.

This relands commit b0e8667b, which was
reverted in 6963be12, with a fix to a unittest
which was incorrectly rewritten before.

Reviewed By: arjunp

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

Instead of summing leading zeros on the input operands, multiply the
max possible values of those inputs and count the leading zeros of
the result. This can give us an extra zero bit (typically in cases
where one of the operands is a known constant).

This allows folding away the remaining 'add' ops in the motivating
bug (modeled in the PhaseOrdering IR test):
https://github.com/llvm/llvm-project/issues/48399

Fixes #48399

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

Need to check for the number of the unique non-constant values since the
unique values may include several constants.

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

This patch enables divergence predicates for min/max nodes.
It makes ISD::MIN/MAX selected to S_MIN_I(U)32/S_MAX_I(U)32 or V_MIN_I(U)32_e64/V_MAX_I(U)32_e64

Reviewed By: rampitec

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

The "not" is defined as XOR $src -1.
 We need to transform this pattern to either S_NOT_B32 or V_NOT_B32_e32
 dependent on the "xor" node divergence.

Reviewed By: rampitec, foad

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

Add a summary provider which can print char[] members at the ends of
structs.

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

Now that the test uses a yaml file for creating binaries, we can run in
anywhere.

CallDescriptionMap benefits from a range constructor when the
CallDescription and mapped type pairs cannot be constructed at once, but
are built incrementally.

Reviewed By: steakhal

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

CallDescriptionMap is supposed to be immutable and opaque about the
stored CallDescriptions, but moving a CallDescriptionMap does not
violate these principles.

Reviewed By: steakhal

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

It was already possible to create an AttributeList from an Index
and an AttributeSet. However, this would actually end up using
the implicit constructor on AttrBuilder, thus doing an unnecessary
conversion from AttributeSet to AttrBuilder to AttributeSet.
Instead we can accept the AttributeSet directly, as that is what
we need anyway.

cannot pass object of non-trivial type
'lldb_private::python::PythonObject' through variadic function

This starts to fix the other half of the lifetime problems in this code
-- dangling references. SB objects created on the stack will go away
when the function returns, which is a problem if the python code they
were meant for stashes a reference to them somewhere.  Most of the time
this goes by unnoticed, as the code rarely has a reason to store these,
but in case it does, we shouldn't respond by crashing.

This patch fixes the management for a couple of SB objects (Debugger,
Frame, Thread). The SB objects are now created on the heap, and
their ownership is immediately passed on to SWIG, which will ensure they
are destroyed when the last python reference goes away. I will handle
the other objects in separate patches.

I include one test which demonstrates the lifetime issue for SBDebugger.
Strictly speaking, one should create a test case for each of these
objects and each of the contexts they are being used. That would require
figuring out how to persist (and later access) each of these objects.
Some of those may involve a lot of hoop-jumping (we can run python code
from within a frame-format string). I don't think that is
necessary/worth it since the new wrapper functions make it very hard to
get this wrong.

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

Also:
- refactor out `__voidify`;
- use the `destroy` algorithm internally;
- refactor out helper classes used in tests for `uninitialized_*`
  algorithms.

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

Before this patch, the code:
```
template <class T>
concept a_concept = X<>;
namespace B {
struct b_struct {};
} // namespace B
```
with config:
```
NamespaceIndentation: None
```

was wrongly indented inside namespace B, giving:
```
template <class T>
concept a_concept = X<>;
namespace B {
  struct b_struct {};
} // namespace B
```

Fixes https://github.com/llvm/llvm-project/issues/50645

Reviewed By: MyDeveloperDay, owenpan

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

This reverts commit b0e8667b.

ASAN/UBSAN bot is broken with this trace:

[ RUN      ] FlatAffineConstraintsTest.FindSampleTest
llvm-project/mlir/include/mlir/Support/MathExtras.h:27:15: runtime error: signed integer overflow: 1229996100002 * 809999700000 cannot be represented in type 'long'
    #0 0x7f63ace960e4 in mlir::ceilDiv(long, long) llvm-project/mlir/include/mlir/Support/MathExtras.h:27:15
    #1 0x7f63ace8587e in ceil llvm-project/mlir/include/mlir/Analysis/Presburger/Fraction.h:57:42
    #2 0x7f63ace8587e in operator* llvm-project/llvm/include/llvm/ADT/STLExtras.h:347:42
    #3 0x7f63ace8587e in uninitialized_copy<llvm::mapped_iterator<mlir::Fraction *, long (*)(mlir::Fraction), long>, long *> include/c++/v1/__memory/uninitialized_algorithms.h:36:62
    #4 0x7f63ace8587e in uninitialized_copy<llvm::mapped_iterator<mlir::Fraction *, long (*)(mlir::Fraction), long>, long *> llvm-project/llvm/include/llvm/ADT/SmallVector.h:490:5
    #5 0x7f63ace8587e in append<llvm::mapped_iterator<mlir::Fraction *, long (*)(mlir::Fraction), long>, void> llvm-project/llvm/include/llvm/ADT/SmallVector.h:662:5
    #6 0x7f63ace8587e in SmallVector<llvm::mapped_iterator<mlir::Fraction *, long (*)(mlir::Fraction), long> > llvm-project/llvm/include/llvm/ADT/SmallVector.h:1204:11
    #7 0x7f63ace8587e in mlir::FlatAffineConstraints::findIntegerSample() const llvm-project/mlir/lib/Analysis/AffineStructures.cpp:1171:27
    #8 0x7f63ae95a84d in mlir::checkSample(bool, mlir::FlatAffineConstraints const&, mlir::TestFunction) llvm-project/mlir/unittests/Analysis/AffineStructuresTest.cpp:37:23
    #9 0x7f63ae957545 in mlir::FlatAffineConstraintsTest_FindSampleTest_Test::TestBody() llvm-project/mlir/unittests/Analysis/AffineStructuresTest.cpp:222:3

This method is more suitable as an opinterface: it seems intrinsic to
individual instances of the operation instead of the dialect.
Also remove the restriction on the interface being applicable to the entry block only.

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

The UpperBound of RVV type in debug info should be elements count minus one,
as the LowerBound start from zero.

Reviewed By: HsiangKai

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

For now if we check `clang --help`, it doesn't show `-fopenmp-version`. This option
should be visible to users. In addition, it is not set to hidden in
`clang/include/clang/Driver/Options.td` as well. The reason it doesn't show is
there is no corresponding helper text. This patch simply adds it.

Reviewed By: jdoerfert

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

Summary: This patch records the access flag for
class/struct/union types in the clang part.

The summary of binary size change and debug info size change due to the DW_AT_accessibility attribute are as the following table. They are built with flags of `clang -O0 -g` (no -gz).

| section | before | after | change | % |
| .debug_loc | 929821 | 929821 |0|0|
|.debug_abbrev | 5885289 | 5971547 |+86258|+1.466%|
|.debug_info | 497613455 | 498122074 |+508619|+0.102%|
|.debug_ranges | 45731664 | 45731664 |0|0|
|.debug_str | 233842595 | 233839388 |-3207| -0.001%|
|.debug_line | 149773166 | 149764583 |-8583|-0.006%|
|total (debug) |933775990 |934359077|+583087 |+0.062%|

|total (binary) |1394617288 | 1395200024| +582736|+0.042%|

Reviewed By: dblaikie, shchenz

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

Based on D111692. Zvamo is not part of the 1.0 V spec. Remove it.

Reviewed By: arcbbb

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

This makes use of the code in D114013 to fold away unnecessary
CMPZ/CSINC starting from a CMOV, in a similar way to how we fold away
CSINV/CSINC/etc

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

`Message()` lambda uses `Reason.Details` as an input parameter for `llvm::formatv()`, but `Reason` in `Message()` is a local object.
Return value of `llvm::formatv()` contains references to its input arguments, thus `Message()` returns an object which contains a reference to `Details` field of the local object `Reason`.
This patch fixes this behavior by passing `Reason` as a reference to `Message()` to ensure that return value of `Message()` contains references to alive object and also prevents copying of `InvalidName` structure at passing it to `makeError()`.

Provided test passes on Linux+GCC with or without this patch, but fails on Windows+VisualStudio without this patch.

Reviewed By: sammccall

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

This is the last cleanup step resulting from D115804 .
Now that clang uses intrinsics when we're in the special FP mode,
we don't need a function attribute as an indicator to the backend.
The LLVM part of the change is in D115885.

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

This is a purely mechanical patch moving some functionality out from the
`Simplex` class out into a `SimplexBase` class. This pavees the way for
a future patch adding support for lexicographic optimization with a class
`LexSimplex`, which will inherit from `SimplexBase`. Inheriting directly
from `Simplex` would bring many additional functions that would not work in
`LexSimplex` because it operates slighty differently from `Simplex`. So We
split out only the basic functionality it needs to inherit into `SimplexBase`.

Reviewed By: Groverkss

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

Make AsyncParallelForRewrite parameterizable with a cost model which drives deciding the parallelization granularity.

Reviewed By: ezhulenev, mehdi_amini

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

Pull out the WriteMove schedule class into the cvt_mask_by_elt_width wrapper

When the source has a series of assignments, users reasonably want to
have the debugger step through each one individually. Turn off the combine
for adjacent stores so we get this behavior at -O0.

Similar to D7181.

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

Depends on https://reviews.llvm.org/D116000.

Added test cases from the comments on https://reviews.llvm.org/D114583.

Reviewed By: MyDeveloperDay

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

It appears that this regressed the formatting of initializer lists in some
cases, see comments on https://reviews.llvm.org/D114583. I'll follow-up
by adding regression tests for these.

This reverts commit c41b3b0f.

Reviewed By: MyDeveloperDay

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

This commit rewrites most existing unittests involving FlatAffineConstraints to use the parsing utility. This helps to make the tests more understandable.

Reviewed By: arjunp

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

https://github.com/llvm/llvm-project/commit/65d7fd0239bf301c5dcaa26ed474200845966136

Match order of most of the other integer opcode combines

The IceLake scheduler model is still mainly a copy of the SkylakeServer model.

This patch adjusts the fp shuffle classes to account for most instructions now working on Port 1 as well as Port 5.

This is based off Agner + uops.info as well as the PR48110 report.

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