[libc] add CPU_COUNT macro and backing function

Add the macro CPU_COUNT as well as a backing function to implement the
functionality.

Reviewed By: sivachandra

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

[mlir][sparse] Add an attribute to the sort operator for stable sorting.

Reviewed By: aartbik

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

[lld-macho] Mark aliased symbols as noDeadStrip

This matches ld64 behavior

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

buildbot-based-debugging a Microsoft lldb test XPASS

Let's see if it's been fixed by my recent ABI fixes...

[NFC] Fix warning wiht parens in assert from 1376c7

[lld-macho][test] Add -lSystem to all lld invocations

This is a requirement from ld64, so this mirrors that expectation. Most
of these changes were just offsets from adding the library, or adding
dyld_stub_binder which is always added when linking ld64. This also adds
`%no-lsystem-lld` for the few cases where we're explicitly testing
things without that.

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

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

Revert "Reapply [InstCombine] Switch foldOpIntoPhi() to use InstSimplify"

This reverts commit e1dd2cd063785ea3a6004c8d173f13113b1b8265 because
the original commit b20e34b39f72f2be035dfb7367b6880fd2cf213a had
a dramatic increase in the build time of RTfuzzer, which caused Fuchsia
Clang toolchain builders to timeout:
https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8801248587754572961/overview

[lld/mac] With -demangle, strip leading _ from non-mangled names

For

    void f();
    int main() { f(); }

`lld -demangle` now produces

    ld64.lld: error: undefined symbol: f
    >>> referenced by path/to/main.o:(symbol main+0x8)

instead of

    ld64.lld: error: undefined symbol: _f
    >>> referenced by path/to/main.o:(symbol _main+0x8)

previously. (Without `-demangle`, it still prints `_f` and `_main`.)

This does *not* match ld64's behavior, but it does match e.g. lld/COFF's
behaviour.

This is arguably easier to understand: clang prepends symbol names with `_`
on macOS, so it seems friendly if the linker removes it again in its
diagnostics. It also makes the `extern "C"` insertion diagnostics we added
recently look more self-consistent.

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

[llvm-objdump] Add --build-id flag for debuginfod lookups without binary.

Adding a --build-id flag allows handling binaries that are referenced in
logs from remote systems, but that aren't necessarily present on the
local machine. These are fetched via debuginfod and handled as if they
were input filenames.

Reviewed By: jhenderson, MaskRay

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

[gn build] port 77945a344c3d

[ExecutionEngine] Enable ExecutionEngine regression tests on AArch64.

[LoopVersioning,LLE] Clear LoopAccessInfoManager after making changes.

Loop versioning changes the control-flow, which may impact SCEVs cached
by for other loops in LoopAccessInfoManager. Clear the manager after
making changes.

Fixes #57825.

Depends on D134609.

Reviewed By: aeubanks

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

[libc] implement basic rand and srand

This provides the reference implementation of rand and srand. In future
this will likely be upgraded to something that supports full ints.

Reviewed By: sivachandra

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

[flang][tco] Engineering option for running only CodeGen passes.

This option allows running only CodeGen passes and then translating
FIR to LLVM IR. I am using it to fetch optimized FIR after bbc,
hand-modify it and then produce LLVM IR that can be fed to clang.

MSVC ABI: Looks like even non-aarch64 uses the MSVC/14 definition for pod/aggregate passing

Details posted here: https://reviews.llvm.org/D119051#3747201

3 cases that were inconsistent with the MSABI without this patch applied:
  https://godbolt.org/z/GY48qxh3G - field with protected member
  https://godbolt.org/z/Mb1PYhjrP - non-static data member initializer
  https://godbolt.org/z/sGvxcEPjo - defaulted copy constructor

I'm not sure what's suitable/sufficient testing for this - I did verify
the three cases above. Though if it helps to add them as explicit tests,
I can do that too.

Also, I was wondering if the other use of isTrivialForAArch64MSVC in
isPermittedToBeHomogenousAggregate could be another source of bugs - I
tried changing the function to unconditionally call
isTrivialFor(AArch64)MSVC without testing AArch64 first, but no tests
fail, so it looks like this is undertested in any case. But I had
trouble figuring out how to exercise this functionality properly to add
test coverage and then compare that to MSVC itself... - I got very
confused/turned around trying to test this, so I've given up enough to
send what I have out for review, but happy to look further into this
with help.

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

[AArch64] Ensure condition (SUBS) has no uses of value in performCONDCombine

performCONDCombine removes and 0xff in patterns of
SUBS (and (add(..), 0xff), C)
under certain complex conditions. It doesn't come up often,
but in the lowering of usub.sat where the SUBS is both used as a
condition and as a value, the And is removed where it would only be
valid for the condition.

Fixes #58109.

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

MSVC AArch64 ABI: Homogeneous aggregates

Fixes:
Protected members, HFA: https://godbolt.org/z/zqdK7vdKc
Private members, HFA: https://godbolt.org/z/zqdK7vdKc
Non-empty base, HFA: https://godbolt.org/z/PKTz59Wev
User-provided ctor, HFA: https://godbolt.org/z/sfrTddcW6

Existing correct cases:
Empty base class, NonHFA: https://godbolt.org/z/4veY9MWP3
 - correct by accident of not allowing bases at all (see non-empty base
   case/fix above for counterexample)
Polymorphic: NonHFA: https://godbolt.org/z/4veY9MWP3
Trivial copy assignment, HFA: https://godbolt.org/z/Tdecj836P
Non-trivial copy assignment, NonHFA: https://godbolt.org/z/7c4bE9Whq
Non-trivial default ctor, NonHFA: https://godbolt.org/z/Tsq1EE7b7
 - correct by accident of disallowing all user-provided ctors (see
   user-provided non-default ctor example above for counterexample)
Trivial dtor, HFA: https://godbolt.org/z/nae999aqz
Non-trivial dtor, NonHFA: https://godbolt.org/z/69oMcshb1
Empty field, NonHFA: https://godbolt.org/z/8PTxsKKMK
 - true due to checking for the absence of padding (see comment in code)

After a bunch of testing, this fixes a bunch of cases that were
incorrect. Some of the tests verify the nuances of the existing
behavior/code checks that were already present.

This was mostly motivated by cleanup from/in D133817 which itself was
motivated by D119051.

By removing the incorrect use of isTrivialForAArch64MSVC here & adding
more nuance to the homogeneous testing we can more safely/confidently
make changes to the isTrivialFor(AArch64)MSVC to more properly align
with its usage anyway.

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

[clang-tools-extra] [clangd] Respect llvm_shlib_dir in tests

Add llvm_shlib_dir to variables used in clangd test suite, consistently
to how it is used in the test suites of clang, clang-tools-extra
and a few other components.  This is necessary to ensure that
the correct shared libraries are used when building clang standalone --
otherwise, use_clang() sets LD_LIBRARY_PATH to the directory containing
the earlier system installation of clang rather than the just-built
library.

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

[clang] fix generation of .debug_aranges with LTO

Right now in case of LTO the section is not emited:

    $ cat test.c
    void __attribute__((optnone)) bar()
    {
    }
    void __attribute__((optnone)) foo()
    {
            bar();
    }
    int main()
    {
            foo();
    }

    $ clang -flto=thin -gdwarf-aranges -g -O3 test.c
    $ eu-readelf -waranges a.out  | fgrep -c -e foo -e bar
    0

    $ clang -gdwarf-aranges -g -O3 test.c
    $ eu-readelf -waranges a.out  | fgrep -c -e foo -e bar
    2

Fix this by passing explicitly --plugin-opt=-generate-arange-section.

Suggested-by: OCHyams <orlando.hyams@sony.com>
Reviewed By: dblaikie, MaskRay

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

[Clang] fix -Wvoid-ptr-dereference for gnu89

Follow up to D134702; it looks like we were still warning for gnu89
mode.

Link: https://reviews.llvm.org/D134702
Link: https://github.com/ClangBuiltLinux/linux/issues/1720#issuecomment-1265738778
Reviewed By: aaron.ballman

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

[sparse] Make GenericOpSparsifier not crash on multi-output dense linalg.generic

The actual transformation doesn't support multi-output GenericOps, but
if we encounter one without sparse annotations we can just leave it
alone.

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

[clang][deps] NFC: Respect working directory on construction

This patch provides `FileManager` with the CWD on construction in the worker, rather than later in the action.

Depends on D134976.

Reviewed By: benlangmuir

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

[clang][deps] Abolish FileManager sharing

This patch removes the ability of a dependency scanning worker to share a `FileManager` instance between individual scans. It's not sound and doesn't provide performance benefits (due to the underlying caching VFS).

Reviewed By: benlangmuir

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

[clangd] Don't print locations of anonymous tags

These are usually not interesting when clangd presents results in
context, and the file paths are noisy.

[flang] Lower TYPE(*) as fir.box<none>

This patch lowers `TYPE(*)` correctly to fir.box<none>.

Reviewed By: jeanPerier

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

[DAGCombiner] [AMDGPU] Allow vector loads in MatchLoadCombine

Since SROA chooses promotion based on reaching load / stores of allocas, we may run into scenarios in which we alloca a vector, but promote it to an integer. The result of which is the familiar LoadCombine pattern (i.e. ZEXT, SHL, OR). However, instead of coming directly from distinct loads, the elements to be combined are coming from ExtractVectorElements which stem from a shared load.

This patch identifies such a pattern and combines it into a load.

Change-Id: I0bc06588f11e88a0a975cde1fd71e9143e6c42dd

[libc] Add a minimal implementation of the POSIX fork function.

A very simple and minimal implementation of fork is added. Future
changes will add more functionality to satisfy POSIX and Linux
requirements.

An implementation of wait and a few support macros in sys/wait.h
have also been added to help with testing the fork function.

Reviewed By: lntue, michaelrj

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

[mlir][arith] Mark unknown types legal in WIE

Allow unknown types to pass through without being marked as illegal.

Reviewed By: antiagainst

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

[mlir][gpu] Fix GCC -Wparenthesis warning

[Clang] make canonical AutoType constraints-free

As @mizvekov suggested in D134772. This works great for D128750 when
dealing with AutoType's.

Reviewed By: mizvekov, erichkeane

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

[NFC][LoopInterchange] Clean up of irrelevent dependency checking with
isOuterMostDepPositive()

The function isOuterMostDepPositive() is checked after negative dependence
vectors are normalized to be non-negative, so there will not be any negative
dependency ('>' as the outermost non-equal sign) after normalization. And
therefore the check in isOuterMostDepPositive() is irrelevent and redundant.

Reviewed By: congzhe

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

[mlir][sparse] support singleton in loop emitter.

Reviewed By: aartbik

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

[clang] Unify Sema and CodeGen implementation of isFlexibleArrayMemberExpr

Turn it into a single Expr::isFlexibleArrayMemberLike method, as discussed in

        https://discourse.llvm.org/t/rfc-harmonize-flexible-array-members-handling

Keep different behavior with respect to macro / template substitution, and
harmonize sharp edges: ObjC interface now behave as C struct wrt. FAM and
-fstrict-flex-arrays.

This does not impact __builtin_object_size interactions with FAM.

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

[AArch64] Don't form paired loads from epilogue operations on Windows

AArch64LoadStoreOptimizer has a bunch of different guards to avoid
corrupting Windows SEH prologues/epilogues, but apparently we missed the
case of merging two instructions where the first instruction isn't part
of the epilogue, but the second instruction is.

Fixes issue discovered at https://reviews.llvm.org/D130049#3704064

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

[llvm-objdump] [debuginfod] Fetch for very-stripped binaries.

When a binary is missing section headers or symbols, objdump can't
provide as good of a disassembly. This change makes objdump try to fetch
a better verion of the binary by its build ID.

Reviewed By: jhenderson

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

Turn off the warning that the undefined behavior I am using in
a test generates.  The green dragon bot compiler is treating this
warning as an error for some reason, hopefully this will calm its
worries.

[clang] Add fix-it note to defaulted-function-deleted warning

Adds a fix to the diagnostic of replacing the `= default` to `= delete`

Reviewed By: aaron.ballman

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

[clang][DebugInfo] Respect fmodule-file-home-is-cwd in skeleton CUs for clang modules

When -fmodule-file-home-is-cwd and the path to the PCM is relative, we
shouldn't assume that the path to the PCM is relative to the modulemap
that produced it. To respect the option -fmodule-file-home-is-cwd, we
should assume the path is relative to the current working directory.

Reviewed By: rmaz

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

[objdump] Support finding --source via --dsym files

Add support for auto-detecting or specifying dSYM files/directories to
allow interleaving source with disassembly.

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

Patch by Jim Radford.

[mlir][sparse] fixed typo in fix of bazel fix

Reviewed By: cota

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

[clang-tools-extra] [test] Use CLANG_NO_DEFAULT_CONFIG=1

Set CLANG_NO_DEFAULT_CONFIG=1 for clang-tools-extra tests to prevent
the system configuration files for clang from affecting the test
results.

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

Remove accidentially left assertion

[mlir][sparse] fix bazel breakage

Reviewed By: cota

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

[lldb][test] Skip import-std-module/vector tests

These tests have begun failing starting with commit
`69a6417406a1b0316a1fa6aeb63339d0e1d2abbd`, which
added a new `import` to `ASTNodeImporter::VisitTypedefType`.
This trips an assertion in following way:
1. When creating a persistent variable for the result we call `CopyType`
   (in `DeportType`) under a `CompleteTagDeclsScope` (which is supposed to complete all
   decls newly imported in the `CopyType` call).
2. During `CopyType` we call `ASTNodeImporter::VisitTypedefType`
3. This now has a second import call on the desugared type
4. In `ASTImporterDelegate::ImportImpl` we will now try to import a decl
   that we originally got from the `std` module (which means it has no valid origin).
   But since we’re doing this under a CompleteTagDeclsScope, the
   `NewDeclListener::NewDeclImported` adds the decl to the list of decls to
   complete after the `CopyType` call. But this list shouldn’t contain decls
   with invalid origins because we assert this in `~CompleteTagDeclsScope`, which
   is where the tests crash.

We suspect that we previously didn’t see this assert trigger because by the time
we create the result variable we are using an AST whose decls all have
a valid debug-info origin (constructed with the help of the std module).
So we never expected decls from modules to be imported under
`CompleteTagDeclsScope` without a m_sema available (which is the case by
the time we get to `DeportType`). Since there is no `m_sema` available,
`CxxModuleHandler::Import` trivially returns and the decls don’t get added
to the `m_decls_to_ignore` list and count as "newly imported decls".

Skip this test for now until we have a fix or the origin tracking gets
refactored (see https://reviews.llvm.org/D101950).

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

[DirectX] Generate `dx.resources` metadata entry

This code adds initial support for generating the HLSL resources
metadata entries. It has a lot of `FIXMEs` laying around because there
is a lot more work to do here, but this lays a solid groundwork and can
accurately handle some trivial cases.

I've filed a swath of issues covering the deficiencies here and left the
issues in comments so that we can easily follow them.

One big change to make sooner rather than later is to move some of this
code into a new libLLVMFrontendHLSL so that we can share it with the
Clang CodeGen layer.

Reviewed By: python3kgae

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

Implement DR2565: Invalid types in the parameter-declaration-clause of a
 requires-expression

As reported: https://github.com/llvm/llvm-project/issues/57487

We properly treated a failed instantiation of a concept as a
unsatisified constraint, however, we need to do this at the 'requires
clause' level as well.  This ensures that the parameters on a requires
clause that fail instantiation will cause a satisfaction failure.

This patch implements this by running requires parameter clause
instantiation under a SFINAE trap, then stores any such failure as a
requirement failure, so it can be diagnosed later.

[clang][driver][darwin] Ensure that the SDK version passed to -platform_version has a minor version number 0

The linker requires at least a "major.minor" for the SDK version, so it will fail when we don't have
a minor version in the case we don't actually have an SDK info.

[SDAG] don't hoist div/rem through a select with neutral constant

This bug was introduced with D134966.

[x86] add test for select + sdiv neutral constant; NFC

[llvm-objdump] Add --no-addresses as an alias for --no-leading-addr

The output is similar to objdump --no-addresses since binutils 2.35.

Depends on D135039
Close #58088

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

[llvm-objdump] --no-leading-addr: hide inline relocation offsets

It seems to make sense to omit offsets when --no-leading-addr is specified. The output is now closer
to objdump -dr --no-addresses (non-wide output).

Reviewed By: nickdesaulniers

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

[mlir][sparse] Restore case coverage warning fix

This restores the fix from D134925 to make MSVC and clang happy.

Reviewed By: stella.stamenova

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

[libc++][format] Updates to Unicode 15.

This adds support for the new code points in the Extended Grapheme
Cluster algorithm. The algorithm itself has remained unchanged.

The width estimation still follows the rules of the Standard.
@cor3ntin filed
  LWG3780 format's width estimation is too approximate and not forward compatible
to improve the estimate.

Reviewed By: ldionne, #libc

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

[ObjectYAML] Support for basic data in code.

This is a split of D134250.

Supports for parsing and dumping the LC_DATA_IN_CODE contents (as binary
data).

This allows more complete testing of llvm-objdump in D133974.

Reviewed By: Higuoxing

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

[RISCV] Refactor and improve eliminateFrameIndex.

There are few changes mixed in here.

-Try to reuse the destination register from ADDI instead of always
creating a virtual register. This way we lean on the register
scavenger in fewer case.
-Explicitly reuse the primary virtual register when possible. There's
still a case where both getVLENFactoredAmount and handling large
fixed offsets can both create a secondary virtual register.
-Combine similar BuildMI calls by manipulating the Register variables.

There are still a couple early outs for ADDI, but overall I tried to
arrange the code into steps.

Reviewed By: reames

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

[RISCV] Restructure eliminateFrameIndex to share more code. NFC

The old code took two different paths based on whether there is
a scalable offset, but these two paths had some code in common.

The main difference between the two code paths was whether we needed
to create a GPR or not for the ADDI that gets created for RVVSpill.
If we had a scalable offset, the same GPR was used as the destination
for adding the scalable offset and the ADDI. To manage this, we now
cache the scratch register and reuse it if it has already been created.

This is a pre-patch for D135009.

Reviewed By: reames, frasercrmck

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

[mlir][Linalg] NFC - Add result and bbArg pretty printing to linalg.reduce

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

[ObjectYAML][MachO] Encode export trie address as ULEB128, not as SLEB128

The `dumpExportEntry` was dumping everything using signed LEB128, but
the format seems to use unsigned LEB128. This can be cross-checked with
the implementation in MachOObjectFile.cpp, the implementation in LLD's
ExportTrie.cpp, and the implementation in macho2yaml.cpp, which all use
ULEB128 functions..

The difference is only apparent when encoding some values with specific
bit patterns (bit active in the 7th, 14th, ... bits of the binary). The
encoding was not always creating problems in the resulting binaries
because if the extra byte was part of the padding, the result of
decoding it as ULEB128 is the same as decoding as SLEB128, however, the
code of MachOObjectFile.cpp (used by llvm-objdump) checks the buffer
decoding position against the reported length, which triggered an error.

Modified a test that used an address with this pattern (0x3FA0, the 14th
bit is active), to show that a round trip still produces the same
results, and added a check using llvm-objdump to use their extra checks
to verify this implementation.

Reviewed By: pete

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

[mlir][Tensor] NFC - Add result pretty printing to TensorOps

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

Modify the qualified/unqualified getter for TypeOfType; NFC

Post-commit feedback observed that returning the TypeOfKind from the
type instead of a Boolean cleans up code using that interface.

[clang] Correct handling of lambdas in lambda default arguments in dependent contexts.

Previously, a lambda expression in a dependent context with a default argument
containing an immediately invoked lambda expression would produce a closure
class object that, if invoked such that the default argument was used, resulted
in a compiler crash or one of the following assertion failures during code
generation. The failures occurred regardless of whether the lambda expressions
were dependent.

  clang/lib/CodeGen/CGCall.cpp:
  Assertion `(isGenericMethod || Ty->isVariablyModifiedType() || Ty.getNonReferenceType()->isObjCRetainableType() || getContext() .getCanonicalType(Ty.getNonReferenceType()) .getTypePtr() == getContext().getCanonicalType((*Arg)->getType()).getTypePtr()) && "type mismatch in call argument!"' failed.

  clang/lib/AST/Decl.cpp:
  Assertion `!Init->isValueDependent()' failed.

Default arguments in declarations in local context are instantiated along with
their enclosing function or variable template (since such declarations can't
be explicitly specialized). Previously, such instantiations were performed at
the same time that their associated parameters were instantiated. However, that
approach fails in cases like the following in which the context for the inner
lambda is the outer lambda, but construction of the outer lambda is dependent
on the parameters of the inner lambda. This change resolves this dependency by
delyaing instantiation of default arguments in local contexts until after
construction of the enclosing context.
  template <typename T>
  auto f() {
    return [](T = []{ return T{}; }()) { return 0; };
  }

Refactoring included with this change results in the same code now being used
to instantiate default arguments that appear in local context and those that
are only instantiated when used at a call site; previously, such code was
duplicated and out of sync.

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

Reviewed By: erichkeane

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

[InstSimplify] try harder to fold fmul with 0.0 operand

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

This was noted as a missing fold in D134876 (with additional
examples based on issue #58046).

I'm assuming that fmul with a zero operand is rare enough
that the use of ValueTracking will not noticeably increase
compile-time.

This adjusts a PowerPC codegen test that was added with D88388
because it would get folded away and no longer provide coverage
for the bug fix.

[SLP]Try to emit canonical shuffle with undef operand.

In the canonical form of the shuffle the poison/undef operand is the
second operand, the patch tries to emit canonical form for partial
vectorization of the buildvector sequence.
Also, this patch starts emitting freeze instruction for shuffles with undef indices if the second shuffle operan is undef, not poison. It is an initial step to D93818, where undef mask element are treated as returning poison value.

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

[AMDGPU][DAG] Fix insert_vector_elt lowering for 8 bit elements

The bitmask used to extract the bits assumed 16 bit elements and wasn't taking the size of the elements into account.

Reviewed By: arsenm

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

[InstSimplify] add tests for fmul with 0.0 operand; NFC

[InstSimplify] reduce code duplication for fmul folds; NFC

This is a modification of the earlier attempt from:
7b7940f9da80

For fma callers, we only want to swap a 0.0 or 1.0 constant.

[AMDGPU] Always lower SHUFFLE_VECTOR

Make it illegal, remove InstructionSelector logic for it

Reviewed By: arsenm

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

[ISel] Fix crash in new FMA DAG combine

Fix a crash in the FMA combine added by D132837 and amended by D134810.
In cases where the newly created node could be folded, the combiner
would fail this assertion:

llc: DAGCombiner.cpp:268: void (anonymous namespace)::DAGCombiner::AddToWorklist(llvm::SDNode *): Assertion `N->getOpcode() != ISD::DELETED_NODE && "Deleted Node added to Worklist"' failed.

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

[AArch64] Re-generate some checks for itofp and min/max legalization.

[OpenMP][OMPIRBuilder] Add support for order(concurrent) to OMPIRBuilder for SIMD directive

If 'order(concurrent)' clause is specified, then the iterations of SIMD loop
can be executed concurrently.

This patch adds support for LLVM IR codegen via OMPIRBuilder for SIMD loop
with 'order(concurrent)' clause. The functionality added to OMPIRBuilder is
similar to the functionality implemented in 'CodeGenFunction::EmitOMPSimdInit'.

Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D134046

Signed-off-by: Dominik Adamski <dominik.adamski@amd.com>

[LoopVersioning,LLE] Add -S option to runlines.

Detect errors in Windows packaging script

- Detect VS devcmd error (missing VS)
- Detect missing python install
- Show commands executed
- Removed pause (blocking CI usage)

Differential revision: https://reviews.llvm.org/D135138

Reapply [InstCombine] Switch foldOpIntoPhi() to use InstSimplify

Reapply with a fix for the case where an operand simplified back
to the original phi: We need to map this case to the new phi node.

-----

foldOpIntoPhi() currently only folds operations into the phi if all
but one operands constant-fold. The two exceptions to this are freeze
and select, where we allow more general simplification.

This patch makes foldOpIntoPhi() generally simplification based and
removes all the instruction-specific logic. We just try to simplify
the instruction for each operand, and for the (potentially) one
non-simplified operand, we move it into the new block with adjusted
operands.

This fixes https://github.com/llvm/llvm-project/issues/57448, which
was my original motivation for the change.

[SimplifyLibCalls] Retain attributes added by Builder.CreateMem*

This currently does not make much of a difference (only one tests is
affected), but it is helpful e.g. for the out-of-tree CHERI target where
Builder.CreateMemCpy() can add attributes other than parameter alignment.

Reviewed By: nikic

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

[InstCombine] Add test where op of phi simplifies to phi (NFC)

Degenerate case for D134954.

[llvm] Remove libcxx, libcxxabi and libunwind from supported LLVM_ENABLE_PROJECTS

This is a breaking change. If you were passing one of those three runtimes
in LLVM_ENABLE_PROJECTS, you need to start passing them in LLVM_ENABLE_RUNTIMES
instead. The runtimes in LLVM_ENABLE_RUNTIMES will start being built using
the "bootstrapping build" instead, which means that they will be built
using the just-built Clang. This is usually what you wanted anyway.

If you were using LLVM_ENABLE_PROJECTS=all with the explicit goal of
building these three runtimes, you can now use LLVM_ENABLE_RUNTIMES=all
and these runtimes will be built using the bootstrapping build.

NOTE: This is a re-application of 887b8bd733ea which had been reverted
      in 6b03a4fea0b4 because it broke the Sphinx documentation publishers.
      The Sphinx documentation publishers have now been moved to using
      the runtimes build, so this should not be an issue anymore.

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

[mlir] Add fully dynamic constructor to StridedLayoutAttr bindings

Reviewed By: ftynse

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

[MLIR] Simplify affine maps + operands exploiting IV info

Simplify affine expressions and maps while exploiting simple range and
step info of any IVs that are operands. This simplification is local,
O(1) and practically useful in several scenarios. Accesses with
floordiv's and mod's where the LHS is non-negative and bounded or is a
known multiple of a constant can often be simplified. This is
implemented as a canonicalization for all affine ops in a generic way:
all affine.load/store, vector_load/store, affine.apply, affine.min/max,
etc. ops.

Eg: For tiled loop nests accessing buffers this way:

affine.for %i = 0 to 1024 step 32 {
  affine.for %ii = 0 to 32 {
    affine.load [(%i + %ii) floordiv 32, (%i + %ii) mod 32]
  }
}

// Note that %i is a multiple of 32 and %ii < 32, hence:

(%i + %ii) floordiv 32 is the same as %i floordiv 32
(%i + %ii) mod 32 is the same as %ii mod 32.

The simplification leads to simpler index/subscript arithmetic for
multi-dimensional arrays and also in turn enables detection of spatial
locality (for vectorization for eg.), temporal locality or loop
invariance for hoisting or scalar replacement.

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

[NFC][AMDGPU] Pre-commit test for D134418.

[mlir] Apply ClangTidy performance finding.

loop variable is copied but only used as const reference.

[mlir] relax transform dialect multi-handle restriction

Relax the restriction in the transform dialect interpreter utilities
that expected a payload IR op to be assocaited with at most one
transform IR handle value. This was useful during the initial
bootstrapping to avoid use-after-free error equivalents when a payload
IR op could be erased through one of the handles associated with it and
then accessed through another. It was, however, possible to erase an
ancestor of the payload IR operation in question. The expensive-checks
mode of interpretation is able to detect both cases and has proven
sufficiently robust in debugging use-after-free errors.

Reviewed By: springerm

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

[mlir][transform] Create GPU transform dialect

This revision adds GPU transform dialect. It also introduce a prefix such as "transform.gpu" for all ops related to this dialect.

MLIR already had two GPU transform op in linalg. This revision moves these ops into GPUTransformOps. The Ops are as follows:

`transform.structured.map_nested_foreach_thread_to_gpu_blocks`  -> `transform.gpu.map_foreach_to_blocks`
This op selects the outermost (toplevel) foreach_thread and parallelize across GPU blocks. It can also generate `gpu_launch`.

`transform.structured.map_nested_foreach_thread_to_gpu_threads` -> `transform.gpu.map_nested_foreach_to_threads`
This op parallelizes nested foreach_thread that are inside `gpu_launch` across GPU threads.

It doesn't add new functionality, but there are some minor refactoring of the code.

Reviewed By: ftynse

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

[LibCalls] Cast Char argument to 'int' before calling emitFPutC

The helpers in BuildLibCalls normally expect that the Value
arguments already have the correct type (matching the lib call
signature). And exception has been emitFPutC which casted the Char
argument to 'int' using CreateIntCast. This patch moves the cast to
the caller instead of doing it inside emitFPutC.

I think it makes sense to make the BuildLibCall API:s a bit
more consistent this way, despite the need to handle the int cast
in two different places now.

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

[BuildLibCalls] Use TLI to get 'int' and 'size_t' type sizes

Stop assuming that an 'int' is 32 bits in helpers that emit libcalls
to lib functions that had 'int' in the signature. For most targets
this is NFC. For a target with 16 bit 'int' type this could help out
detecting if trying to emit a libcall with incorrect signature.

Similarly we now derive the type mapping to 'size_t' by asking TLI
about the size of 'size_t'. This should be NFC (at least for in-tree
targets) since getSizeTSize(), in TLI, is deriving the size in the
same way as DataLayout::getIntPtrType().

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

[BuildLibCalls] Name types to identify when 'int' and 'size_t' is assumed. NFC

Lots of BuildLibCalls helpers are using Builder::getInt32Ty to get
a type matching an 'int', and DataLayout::getIntPtrType to get a
type matching 'size_t'. The former is not true for all targets, since
and 'int' isn't always 32 bits. And the latter is a bit weird as well
as the definition of DataLayout::getIntPtrType isn't clearly mapping
it to 'size_t'.

This patch is not aiming at solving any such problems. It is merely
highlighting when a libcall is expecting to use 'int' and 'size_t'
by naming the types as IntTy and SizeTTy when preparing the type
signatures for the emitted libcalls.

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

[LAA] Pass LoopAccessInfoManager instead of GetLAA function.

Use LoopAccessInfoManager directly instead of various GetLAA lambdas.

Depends on D134608.

Reviewed By: aeubanks

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

Revert "[AArch64][GlobalISel] Fold away lowered vector sign-extend of vector compares."

This reverts commit dcd02a524befcec71f46ab76d725b2a8f8623d69.

We should instead use the generic combine.

[ValueTracking] Handle constant exprs in isKnownNonZero()

Handle constant expressions by falling through to the general
operator-based code. In particular, this adds support for bitcast
and GEP expressions.

[lld-macho] Add support for emitting chained fixups

This commit adds support for chained fixups, which were introduced in
Apple's late 2020 OS releases. This format replaces the dyld opcodes
used for supplying rebase and binding information, and encodes most of
that data directly in the memory location that will have the fixup
applied.

This reduces binary size and is a requirement for page-in linking, which
will be available starting with macOS 13.

A high-level overview of the format and my implementation can be found
in SyntheticSections.h.

This feature is currently gated behind the `-fixup_chains` flag, and
will be enabled by default for supported targets in a later commit.

Like in ld64, lazy binding is disabled when chained fixups are in use,
and the `-init_offsets` transformation is performed by default.

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

Add reverse load pattern tests

[SimpleLoopUnswitch] Clear block and loop dispos after destroying loop.

SimpleLoopUnswitch may remove loops. Clear block and loop dispositions,
to clean up invalid entries in the cache.

Fixes #58136.

[SimplifyLibCalls] Place deref attr even if nonnull already set

If nonnull is already set, we currently skip setting both nonnull
and dereferenceable. Make these independent, to avoid regressions
when additional nonnull attributes are inferred earlier.

Revert "[InstCombine] Switch foldOpIntoPhi() to use InstSimplify"

This reverts commit b20e34b39f72f2be035dfb7367b6880fd2cf213a.

This causes RAUW type mismatch assertions on some buildbots,
reverting for now.

[ValueTracking] Avoid known bits fallthrough for freeze (NFCI)

The known bits logic should never produce a better result than
the direct recursive non-zero query here, so skip the fallthrough.

[ValueTracking] Switch isKnownNonZero() to switch over opcodes (NFCI)

The change in the assume-queries-counter.ll test is because we skip
and unnecessary known bits query for arguments.

[mlir][tensor][NFC] Rename linalg.init_tensor to tensor.empty

tensor.empty/linalg.init_tensor produces an uninititalized tensor that can be used as a destination operand for destination-style ops (ops that implement `DestinationStyleOpInterface`).

This change makes it possible to implement `TilingInterface` for non-destination-style ops without depending on the Linalg dialect.

RFC: https://discourse.llvm.org/t/rfc-add-tensor-from-shape-operation/65101

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

[InstCombine] Switch foldOpIntoPhi() to use InstSimplify

foldOpIntoPhi() currently only folds operations into the phi if all
but one operands constant-fold. The two exceptions to this are freeze
and select, where we allow more general simplification.

This patch makes foldOpIntoPhi() generally simplification based and
removes all the instruction-specific logic. We just try to simplify
the instruction for each operand, and for the (potentially) one
non-simplified operand, we move it into the new block with adjusted
operands.

This fixes https://github.com/llvm/llvm-project/issues/57448, which
was my original motivation for the change.

[flang] Lower polymorphic entities types in dummy argument and function result

This patch updates lowering to produce the correct fir.class types for
various polymorphic and unlimited polymoprhic entities cases. This is only the
lowering. Some TODOs have been added to the CodeGen part to avoid errors since
this part still need to be updated as well.
The fir.class<*> representation for unlimited polymorphic entities mentioned in
the document has been updated to fir.class<none> to avoid useless work in pretty
parse/printer.

This patch is part of the implementation of the poltymorphic
entities.
https://github.com/llvm/llvm-project/blob/main/flang/docs/PolymorphicEntities.md

Depends on D134957

Reviewed By: jeanPerier

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

[LAA] Use LoopAccessInfoManager in legacy pass.

Simplify LoopAccessLegacyAnalysis by using LoopAccessInfoManager from
D134606. As a side-effect this also removes printing support from
LoopAccessLegacyAnalysis.

Depends on D134606.

Reviewed By: aeubanks

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

[gn build] Port 6d9eb5332913