Currently, we handle it as a symbol without a header. In general, for
the include-cleaner case, the std::get comes with the type header, it is
safe to ignore it.

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

applyLoopGuards doesn't always preserve information when there are multiple assumes.

This patch tries to deal with multiple assumes regarding a SCEV's divisibility and min/max values, and rewrite it into a SCEV that still preserves all of the information.
For example, let the trip count of the loop be TC. Consider the 3 following assumes:

1. __builtin_assume(TC % 8 == 0);
2. __builtin_assume(TC > 0);
3. __builtin_assume(TC < 100);

Before this patch, depending on the assume processing order applyLoopGuards could create the following SCEV:
max(min((8 * (TC / 8)) , 99), 1)

Looking at this SCEV, it doesn't preserve the divisibility by 8 information.

After this patch, depending on the assume processing order applyLoopGuards could create the following SCEV:
max(min((8 * (TC / 8)) , 96), 8)

By aligning up 1 to 8, and aligning down 99 to 96, the new SCEV still preserves all of the original assumes.

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

[temp.friend]p9 says

> Such a constrained friend function or function template declaration does
not declare the same function or function template as a declaration in
any other scope.

But the friend declaration in the same scope shouldn't fall into this
catagory. Although the logic is handled in 'FriendsDifferByConstraints',
the compiler may haven't merged the lexcial declcontext in time.
Also the code removed is not covered by test too.

Let's handle the logic in sema as we've done now.

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

Treating constructor calls when the type name isn't explicitly spelled
can cause spurious results, so turn them into implicit references.
This doesn't change the behaviour for constructor calls that explicitly spell
the type name, as we should see a reference through the typeloc.

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

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

This adds a bit of coverage for GlobalISel.

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

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

Currently, the insertion point for `bubbleUpPackOpThroughElemGenericOp`
is after the tensor.pack this means that the new generic will be created
right after the tensor.pack. This is inconvenient because we are moving
the position of the generic; the idea is to move pack/unpack around, not
linalg.generics. This PR changes the insertion point to preserve the
position of the generic.

Additionally, it restricts the pattern to fire if the generic has a
single user (`tensor.pack`) to avoid introducing recomputation.

Reviewed By: hanchung

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

The previous code was always emitting two genAssign calls to create
a temporary copy of the RHS if it could overlap with the LHS.

This inline temporary creation is not needed anymore after:
https://github.com/llvm/llvm-project/commit/755535b5eb5f6d60e9cc347cecd9e057231b92bb
that updated the assignment runtime to detect overlap and make a
temporary copy in the runtime directly.

Note that optimized inlined assignment will still have to do the alias
analysis to skip the copy when added later.

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

Remove the IR modification callbacks from `OperationFolder`. Instead, an optional `RewriterBase::Listener` can be specified.
* `processGeneratedConstants` => `notifyOperationCreated`
* `preReplaceAction` => `notifyOperationReplaced`

This simplifies the GreedyPatternRewriterDriver because we no longer need special handling for IR modifications due to op folding.

A folded operation is now enqueued on the GreedyPatternRewriteDriver's worklist if it was modified in-place. (There may be new patterns that apply after folding.)

Also fixes a bug in `TestOpInPlaceFold::fold`. The folder could previously be applied over and over and did not return a "null" OpFoldResult if the IR was not modified. (This is similar to a pattern that returns `success` without modifying IR; it can trigger an infinite loop in the GreedyPatternRewriteDriver.)

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

The size lower bound is known - the `Join` map in both cases gets an entry for
each variable from both input maps (union).

This reduces the number of times the map grows, improving ReleaseLTO-g compile
time for CTMark projects by an average of around 0.2%.

Reviewed By: scott.linder

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

Fix https://github.com/llvm/llvm-project/issues/57693

This adds sys/socket.h and some definitions on Linux.

Reviewed By: sivachandra

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

Since we decided to remove the support for `-fcoroutines-ts` in
clang/llvm17 and the clang16/llvm16 is branched. So we're going to
remove the `-fcoroutines-ts` option.

* This silences msan errors

Close https://github.com/llvm/llvm-project/issues/60864.

We're going to remove the support for `-fcoroutines-ts` in clang. But we
found there are additional use of `-fcoroutines-ts` in clang-tidy. This
patch removes such uses.

The patch ensures last two operands of vp.abs/ctlz/cttz are mask and evl.

Reviewed By: craig.topper

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

This reverts commit e7613c1d.

GCC issues an error:

In file included from /home/buildbot/as-builder-4/lld-x86_64-ubuntu-fast/llvm-project/llvm/unittests/ADT/BitmaskEnumTest.cpp:9:
/home/buildbot/as-builder-4/lld-x86_64-ubuntu-fast/llvm-project/llvm/include/llvm/ADT/BitmaskEnum.h:66:22: error: explicit specialization of template<class E, class Enable> struct llvm::is_bitmask_enum outside its namespace must use a nested-name-specifier [-fpermissive]
   66 |   template <> struct is_bitmask_enum<Enum> : std::true_type {};                \
      |                      ^~~~~~~~~~~~~~~~~~~~~
/home/buildbot/as-builder-4/lld-x86_64-ubuntu-fast/llvm-project/llvm/unittests/ADT/BitmaskEnumTest.cpp:30:1: note: in expansion of macro LLVM_DECLARE_ENUM_AS_BITMASK
   30 | LLVM_DECLARE_ENUM_AS_BITMASK(Flags2, V4);
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is recommit of 2e416cdd, reverted in 8555ab2f, because GCC
complains on extra qualification. The macro LLVM_DECLARE_ENUM_AS_BITMASK
does not specify llvm:: anymore, so the macro must occur in the namespace
llvm. Documentation updated accordingly. The original commit message is below.

With this change bitwise operations are allowed for FPClassTest
enumeration, it must simplify using this type. Also some functions
changed to get argument of type FPClassTest instead of unsigned.

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

This commit improves the "target_teams_distribute_paralle
l_for_simd_codegen.cpp" and "target_teams_distribute_redu
ction_codegen.cpp" tests based upon some of the execution
tests present in the SOLLVE tests. Based on SOLLVE, a new
test "target_task_affinity_codegen.cpp" is also being
added. These tests are required to be added because the
existing tests do not test the combination of directives
these will be testing.

Link to SOLLVE page: https://github.com/SOLLVE/sollve_vv

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

This includes handling of new attributes for symbols & rpath.
In the event that an older format file is compared to tbd_v5, ignore these new attributes.

Reviewed By: ributzka

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

Reviewed By: Amir

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

This introduces R_RISCV_PLT32, PC-relative data relocation that takes
the 32-bit relative offset to a function or its PLT entry from its
relocation location.

This is needed to support relative vtables on RISCV.

Github PR: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/363

The lld handling of this reloc is D143115.

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

The Bazel configs don't set `LLVM_ENABLE_LIBXML2`, so this was never usable to
begin with.

On systems without static `libxml2.a` this made `lld` runtime-dependent on an
unused, non-hermetic `libxml2.so`.

Reviewed By: MaskRay, GMNGeoffrey

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

The posix standard defines an alternate mode for printf where the
conversions also have an index that describes which argument to select.
Due to how variadic arguments work in C, to reach the nth argument all
n-1 previous arguments must be read with their correct types. If the
format string does not specify the types for a continuous set of
arguments, then the arguments after the discontinuity cannot be safely
read. This patch causes all conversions requesting an argument that
comes after a gap be treated as raw (i.e. the conversion string is
printed literally).

Reviewed By: sivachandra

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

This fold was added with https://reviews.llvm.org/D135876 ,
but we missed the one-use check.

This might be the root cause for issue #60632.

This shows a missing extra use check.

Mehdi noted in https://reviews.llvm.org/D144391 that given the low cost of keeping the old `fold` method signature working and the difficulty of writing a `FoldAdaptor` oneself, it'd be nice to keep the support for the sake of Ops written manually in C++.
This patch therefore partially reverts the removal of the old `fold` method by still allowing the old signature to be used. The active use of it is still discouraged and ODS will always generate the new method using `FoldAdaptor`s.

I'd also like to note that the previous ought to have broken some manually defined `fold` methods in-tree that are defined here: https://github.com/llvm/llvm-project/blob/23bcd6b86271f1c219a69183a5d90654faca64b8/mlir/include/mlir/Dialect/Affine/IR/AffineOps.h#L245 It seems like these are not part of the regressions tests however...

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

* Always print out maccatalyst in format
* Traverse symbols via InterfaceFile symbol APIs
* Properly track addition of flags.

Reviewed By: ributzka

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

I missed that the test needed a icelake-server cpu to fail, and left a testing
"false &&" in the if condition. Hopefully this is now the correct fix.

/data/llvm-project/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugAranges.cpp:79:66: error: format specifies type 'unsigned int' but the argument has type 'lldb_private::RangeData<unsigned long, unsigned int, unsigned long>::DataType' (aka 'unsigned long') [-Werror,-Wformat]
      LLDB_LOGF(log, "0x%8.8x: [0x%" PRIx64 " - 0x%" PRIx64 ")", entry->data,
                        ~~~~~                                    ^~~~~~~~~~~
                        %8.8lx
/data/llvm-project/lldb/include/lldb/Utility/Log.h:348:27: note: expanded from macro 'LLDB_LOGF'
      log_private->Printf(__VA_ARGS__);                                        \
                          ^~~~~~~~~~~
1 error generated.

LSR can include Regs of AddRec SCEVs from different loops, which do not combine
well when added in Scalar Evolution. As they should never produce constant
differences so we can just guard against trying to create them.

Fixes #60927

While populating new blocks, we didn't always put them into their own
groups because that needs additional sort for an almost-sorted new
blocks array. However, ensuring all blocks are placed in the right group
enables the fast identifying of unused pages in a group by simply
accouting the number of free blocks are there. Therefore, this commit is
used to set up the invariant for future optimizations.

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

BatchClass is used to manage the free blocks for each size class. It's a
little bit tricky when it has to manage the free blocks of BatchClass.
In general, BatchClass block records the addresses of free blocks. In
order not to waste additional block to record the blocks in BatchClass,
it's self contained, i.e., it'll record its own address. The safety is
maintained by 2 preconditions,

  1. If a block is used to record other BatchClass blocks, it'll also
     record the address itself
  2. While allocating free blocks, all the recorded blcoks will be
     allocated together, which means there's no partial allocation

This CL fixes the violation of 1. and then we can push the free blocks
without having to push them in batches.

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