This just updates debug location of a loop in a LIT test to point
to the correct source line.

isConditionImplied is able to correctly handle 0 or 1 coefficients, so
let it handle those cases, rather than skipping them.

Increase the coverage of standard-conforming and non-conforming
co_sum calls.

Reviewed By: ktras

Guard sqrt_80_bit_long_double.h header to not be included with aarch64.

Reviewed By: sivachandra

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

Makes it easier for later folds and avoids unnecessary 256-bit ops (especially on AVX1-only targets where we miss a lot of integer instructions)

Another step to move away from the legacy PM syntax when specifying
passes in opt.

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

Adding -debugify and -check-debugify in the PassRegistry will make
sure the passes are listed properly by -print-pipeline-passes as
well as -print-passes.

It also allows removal of the custom pipeline parsing callback that
has been used in the NewPMDriver.

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

Rejecting AGPR DS_WRITE instructions before adding them to any mergeable
list seems cleaner than adding them to the list and rejecting them
later.

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

Using separate lists for AGPR and non-AGPR instructions seems like a
cleaner solution than putting them all in the same list and then later
refusing to merge instructions of different AGPR-ness.

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

Change CombineInfo::setMI to take a reference to the
SILoadStoreOptimizer instance, for easy access to common fields like
TII and STM.

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

Use the `llvm-profdata show` command to verify debug info for profile correlation using the `--debug-info` option.

Reviewed By: kyulee

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

There seems to be an issue on x86_64 when launching a ScriptdProcess.
This disables temporarely the test that causes the bot to timeout until
I finish investigating the issue.

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

Exts is a map of keyed by std::string with a extension info as
a value. Making copies of this wouldn't be cheap.

We had a mix of references and copies. This makes everything
consistently use a const reference to make it clear we aren't
modifying it.

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

The type names in the spec are just sugar used by the header generator to
generate the function prototype. Giving the VarArgType a name of "..."
allows the header generator to treat and generate the "type name" for var
arg parameters similar to how it does for any other type.

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

Initially, I had a quick and dirty approach, but it led to a myriad of special cases handling comments (that may add unwrapped lines).
So I added TT_RecordLBrace type annotations and it seems like a much nicer solution.
I think that in the future it will allow us to clean up some convoluted code that detects records.

Reviewed By: MyDeveloperDay, HazardyKnusperkeks

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

Refactor sqrt implementations:
- Move architecture specific instructions from `src/math/<arch>` to `src/__support/FPUtil/<arch>` folder.
- Move generic implementation of `sqrt` to `src/__support/FPUtil/generic` folder and add it as a header library.
- Use `src/__support/FPUtil/sqrt.h` for architecture/generic selections.
- Add unit tests for generic implementation of `sqrt`.

Reviewed By: sivachandra

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

Bitcode upgrade automatically takes in place when the current compiler version doesn't match the one building the input modules. The upgrade is very expansive for large applications and unnecessary when users are sure the two compilers do not have a version issue, even if their versions mismatch literally. An optional to disable the automatic bitcode upgrade will be handy in such case.

Reviewed By: wenlei

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

- Mention pp-trace
- CMake configuration
- Overriding registerPPCallbacks
- Overriding isLanguageVersionSupported
- Check development tips
  - Guide to useful documentation
  - Using the Transformer library
  - Developing your check incrementally
  - Creating private matchers
  - Unit testing helper code
  - Making your check robust
  - Documenting your check
- Describe the Inputs test folder

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

Also switch the implementation of `-arith-bufferize` to BufferizableOpInterface.

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

This commit checks if a function is marked with the naked attribute
and, if it is, will silence the emission of any unused-parameter
warning.

Inside a naked function only the usage of basic ASM instructions is
expected. In this context the parameters can actually be used by
fetching them according to the underlying ABI. Since parameters might
be used through ASM instructions, the linter and the compiler will have
a hard time understanding if one of those is unused or not, therefore
no unused-parameter warning should ever be triggered whenever a
function is marked naked.

Avoid using the libc++ internal `_LIBCPP_HAS_NO_INT128` in our tests.

Reviewed By: #libc, ldionne

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

This should fix the regressions detected in D117992.

This lands before D117992 to avoid breaking main.

Reviewed By: #libc, ldionne

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

I accidentally made this work on the GlobalISel path, and there's no
real reason not to handle this.

This adds the following changes:

* Fold: vselect(<all active predicate>, x, y) => x
* Extend isAllActivePredicate to take vscale_range into account, e.g.
  isAllActivePredicate(vl16) for nxv16i1 and vscale == 1 => true.
  isAllActivePredicate(vl32) for nxv16i1 and vscale == 2 => true.

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

This move is going to be needed in order to reuse `posix_readdir` in
another translation unit. This doesn't change any of the code except
for removing an unused function parameter that otherwise triggers a
warning inside our tests.

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

In `ranges::advance(iter, n, bound)`, we'd incorrectly handle the case
where bound < iter and n is 0:

    int a[10];
    int *p = a+5;
    int *bound = a+3;
    std::ranges::advance(p, 0, bound);
    assert(p - a == 5); // we'd return 3 before this patch

This was caused by an incorrect handling of 0 inside __magnitude_geq.

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

We were missing a constraint in common_iterator's iterator_traits and
we were eagerly instantiating iter_value_t even when invalid.

Thanks to Casey Carter for finding this bug.

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

The patch handles the addition of constant global variables to the table
of contents.

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

When passing a character procedure as a dummy procedure, the result
length must be passed along the function address. This is to cover
the cases where the dummy procedure is declared with assumed length
inside the scope that will call it (it will need the length to allocate
the result on the caller side).

To be compatible with other Fortran compiler, this length must be
appended after all other argument just like character objects
(fir.boxchar).

A fir.boxchar cannot be used to implement this feature because it
is meant to take an object address, not a function address.

Instead, argument like `tuple<function type, integer type> {fir.char_proc}`
will be recognized as being character dummy procedure in FIR. That way
lowering does not have to do the argument split.

This patch adds tools in Character.h to create this type and tuple
values as well as to recognize them and extract its tuple members.

It also updates the target rewrite pass to split these arguments like
fir.boxchar.

This part is part of fir-dev upstreaming. It was reviwed previously
in: https://github.com/flang-compiler/f18-llvm-project/pull/1393

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

I don't think this is actually defined for mesa, but this is what we
were doing on the DAG path.

Users can define aliases for long symbols using import aliases:

    import X = A.B.C;

Previously, these were unhandled and would terminate import sorting.
With this change, aliases sort as their own group, coming last after all
other imports.

Aliases are not sorted within their group, as they may reference each
other, so order is significant.

Revision URI: https://reviews.llvm.org/D118361

[X86][SSE] Add combineBitOpWithShift for BITOP(SHIFT(X,Z),SHIFT(Y,Z)) -> SHIFT(BITOP(X,Y),Z) vector folds

InstCombine performs this more generally with SimplifyUsingDistributiveLaws, but we don't need anything that complex here - this is mainly to fix up cases where logic ops get created late on during lowering, often in conjunction with sext/zext ops for type legalization.

https://alive2.llvm.org/ce/z/gGpY5v

Swizzled accesses are not merged, but there is no particular reason not
to merge two instructions if any of the intervening instructions happens
to be a swizzled access.

This moves the check for swizzled accesses out of checkAndPrepareMerge
into collectMergeableInsts where I think it makes more sense.

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

Precommit some additional tests for D118256.

This test is completely nondeterministic, environment-dependent and does
not test what it was supposed to test (reverting the associated patch
does not make it fail).

I tried to figure out what the patch was meant to fix to see if I can
create a better test with the current tools, but I was not able to
understand the problem (it sounds like it has something to do with local
classes, but I don't understand the details).