Depends On D151505

Reviewed By: aartbik, Peiming

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

(These factories are used in downstream code, despite not being used within the MLIR codebase.)

Depends On D151513

Reviewed By: Peiming

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

Depends On D151505

Reviewed By: Peiming

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

Expression evaluation for `void` valued expressions sets an error using the `kNoResult`
code. Like the `expression` command, `dwim-print` should also not print such errors.

Before:

```
(lldb) dwim-print (void)printf("hi\n")
hi
Error: 'unknown error'
```

After:

```
(lldb) dwim-print (void)printf("hi\n")
hi
```

rdar://109746544

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

In ProcessMachCore::LoadBinariesViaMetadata(), if we did
load some binaries via metadata in the core file, don't
then search for a userland dyld in the corefile / kernel
and throw away that binary list.  Also fix a little bug
with correctly recognizing corefiles using a `main bin spec`
LC_NOTE that explicitly declare that this is a userland
corefile.

LocateSymbolFileMacOSX.cpp's Symbols::DownloadObjectAndSymbolFile
clarify the comments on how the force_lookup and how the
dbgshell_command local both have the same effect.

In PlatformDarwinKernel::LoadPlatformBinaryAndSetup, don't
log a message unless we actually found a kernel fileset.

Reorganize ObjectFileMachO::LoadCoreFileImages so that it delegates
binary searching to DynamicLoader::LoadBinaryWithUUIDAndAddress and
doesn't duplicate those searches.  For searches that fail, we would
perform them multiple times in both methods.  When we have the
mach-o segment vmaddrs for a binary, don't let LoadBinaryWithUUIDAndAddress
load the binary first at its mach-o header address in the Target;
we'll load the segments at the correct addresses individually later
in this method.

DynamicLoaderDarwin::ImageInfo::PutToLog fix a LLDB_LOG logging
formatter.

In DynamicLoader::LoadBinaryWithUUIDAndAddress, instead of using
Target::GetOrCreateModule as a way to find a binary already registered
in lldb's global module cache (and implicitly add it to the Target
image list), use ModuleList::GetSharedModule() which only searches
the global module cache, don't add it to the Target.  We may not
want to add an unstripped binary to the Target.

Add a call to Symbols::DownloadObjectAndSymbolFile() even if
"force_symbol_search" isn't set -- this will turn into a
DebugSymbols call / Spotlight search on a macOS system, which
we want.

Only set the Module's LoadAddress if the caller asked us to do that.

Differential Revision: https://reviews.llvm.org/D150928
rdar://109186357

When printing the root of a value, if it's a reference its children are unconditionally
printed - in contrast to pointers whose children are only printed if a sufficient
pointer depth is given.

However, the children are printed even when there's a summary provider that says not to.
If a summary provider exists, this change consults it to determine if children should be
printed.

For example, given a variable of type `std::string &`, this change has the following
effect:

Before:

```
(lldb) p string_ref
(std::string &) string_ref = "one two three four five six seven eight nine ten": {
  __r_ = {
    std::__1::__compressed_pair_elem<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__rep, 0, false> = {
      __value_ = {
         = {
          __l = (__data_ = "one two three four five six seven eight nine ten", __size_ = 48, __cap_ = 64, __is_long_ = 1)
          __s = (__data_ = "@\0p\U00000001\0`\0\00\0\0\0\0\0\0\0@", __padding_ = "\x80t<", __size_ = '\0', __is_long_ = '\x01')
          __r = {
            __words ={...}
          }
        }
      }
    }
  }
}
```

After:

```
(lldb) p string_ref
(std::string &) string_ref = "one two three four five six seven eight nine ten"
```

rdar://73248786

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

This is part of an effort to migrate from llvm::Optional to std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

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

[clang][ExtractAPI] Modify declaration fragment methods to add a new fragment at an arbitrary offset.

[clang][ExtractAPI] Modify declaration fragment methods to add a new fragment at an arbitrary offset.

The current implementation doesn't support merging declaration fragments at arbitrary offsets. This patch adds that support
by modifying declaration fragment methods.

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

Extra filtering for boltdiff, excluding non-simple functions from comparison.

Reviewed By: #bolt, maksfb

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

This is a major step along the way towards the new STEA design.  While a great deal of this patch is simple renaming, there are several significant changes as well.  I've done my best to ensure that this patch retains the previous behavior and error-conditions, even though those are at odds with the eventual intended semantics of the `dimToLvl` mapping.  Since the majority of the compiler does not yet support non-permutations, I've also added explicit assertions in places that previously had implicitly assumed it was dealing with permutations.

Reviewed By: aartbik

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

These are additional tests for D151596.

This patch introduces FileSpec::GetComponents, a method that splits a
FileSpec's path into its individual components. For example, given
/foo/bar/baz, you'll get back a vector of strings {"foo", "bar", baz"}.

The motivation here is to reduce the use of
`FileSpec::RemoveLastPathComponent`. Mutating a FileSpec is expensive,
so providing a way of doing this without mutation is useful.

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

Reviewed By: ldionne, #libc

Spies: pcwang-thead, libcxx-commits

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

Apple deprecated bitcode in the deployment process in Xcode 14.0. Last
month Apple started requiring Xcode 14.1+ to submit apps to the App
Store. Since there isn't a use for bundling bitcode outside of
submitting to the App Store we should be safe to delete this handling
entirely from LLD.

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

Certifi 2022.12.07 removes root certificates from "TrustCor" from the
root store. These are in the process of being removed from Mozilla's
trust store.

https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/yLohoVqtCgAJ

Currently the PipelineSolver processes SchedGroups in bottom up manner. However, there is no compelling reason to require this. Providing the option to toggle this affords greater experimentation capability, and make usage a bit more intuitive. Importantly, it makes designing rules much easier.

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

Change-Id: Ic4abd3408f9faa105c0eef72eab7873d46083ee4

This is more consistent with how we handle integer widening multiply.

A follow up patch will add support for matching vfwmul when the
multiplicand is being squared.

This patch adds support for `tosa.scatter` lowering in the `--tosa-to-scf` pass. Here's an example for this lowering:

```
func.func @tosa(
                %valuesIn : tensor<3x7x5xi32>,
                %indices : tensor<3x6xi32>,
                %input : tensor<3x6x5xi32>) ->
                tensor<3x7x5xi32> {
        %0 = "tosa.scatter"(%valuesIn, %indices, %input) :
                        (tensor<3x7x5xi32>,
                        tensor<3x6xi32>,
                        tensor<3x6x5xi32>) ->
                        (tensor<3x7x5xi32>)
        return %0 : tensor<3x7x5xi32>
}
```

translates to
  func.func @tosa(%arg0: tensor<3x7x5xi32>, %arg1: tensor<3x6xi32>, %arg2: tensor<3x6x5xi32>) -> tensor<3x7x5xi32> {
    %c0 = arith.constant 0 : index
    %c3 = arith.constant 3 : index
    %c1 = arith.constant 1 : index
    %c6 = arith.constant 6 : index
    %c2 = arith.constant 2 : index
    %c5 = arith.constant 5 : index
    %c0_0 = arith.constant 0 : index
    %c1_1 = arith.con...

The rest of the fetch/op intrinsics were added in e13246a2 but sub
was conspicuous by its absence.

Reviewed By: yaxunl

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

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

Most systems support strerror_r. For the remaining systems (e.g. MSVC) strerror_s and
strerror can be used as fallbacks. We don't have a supported operating
system/compiler that doesn't provide `strerror`.

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

https://github.com/flang-compiler/f18/pull/1068 added a fallback
when strerror is unavailable, but I think the code path is dead.

Reviewed By: serge-sans-paille, vzakhari

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

This fixes breakage introduced by 769d282d.

This patch changes the type of `Preprocessor::MainFileDir` from `const DirectoryEntry *` to `Optional<DirectoryEntryRef>` in order to remove some calls to the deprecated `DirectoryEntry::getName()`.

Depends on D127658.

Reviewed By: bnbarham

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

This patch replaces some calls to the deprecated `DirectoryEntry::getName()` with calls to `DirectoryEntryRef::getName()` in SemaCodeComplete.cpp.

Depends on D127654.

Reviewed By: bnbarham

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

This patch changes the type of `Module::Directory` from `const DirectoryEntry *` to (essentially) `Optional<DirectoryEntryRef>` in order to remove uses of the deprecated `DirectoryEntry::getName()`.

Depends on D127651.

Reviewed By: bnbarham

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

This patch changes the argument type of `ModuleMap::parseModuleMapFile()` from `const DirectoryEntry *` to `DirectoryEntryRef` in order to remove the deprecated uses of `DirectoryEntry::getName()`.

Depends on D127648.

Reviewed By: bnbarham

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

This patch changes the argument type of `ModuleMap::inferFrameworkModule()` from `const DirectoryEntry *` to `DirectoryEntryRef` in order to remove the deprecated uses of `DirectoryEntry::getName()`.

Depends on D127647.

Reviewed By: bnbarham

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

This patch changes the return/argument types of `ModuleMap::{load,lookup}ModuleMap()` from `const FileEntry *` to `FileEntryRef` in order to remove uses of the deprecated `DirectoryEntry::getName()`.

Reviewed By: bnbarham

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

The strings "DarwinLog" and "log" probably do not need to be in the
ConstString StringPool. We still create ConstStrings from them in some
places (for now) but that's because we don't have an implicit
constructor to convert a StringRef to a ConstString.

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

This patch adds an IncomingValueHandler and IncomingValueAssigner, and implements minimal support for lowering formal arguments according to the RISC-V calling convention. Simple non-aggregate integer and pointer types are supported.

In the future, we must correctly handle byval and sret pointer arguments, and instances where the number of arguments exceeds the number of registers.

Coauthored By: lewis-revill

Reviewed By: arsenm

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

This doesn't need to be in the ConstString StringPool. There's little
benefit to having these be unique, and we don't need fast comparisons on
them.

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

Reviewed By: aartbik

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

The last use was removed by:

  commit 6625680a
  Author: Hans Wennborg <hans@chromium.org>
  Date:   Tue Feb 2 14:10:26 2021 +0100

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

- Remove unused parameter `valobj` (I checked downstream, not
  even swift is using it).
- Return a std::pair<StringRef, StringRef> insted of having 2 out
  parameter strings.
- Remove the use of ConstStrings.

This change was primarily mechanical except in
`ObjCLanguage::GetFormatterPrefixSuffix`. To keep this fast, we
construct an llvm::StringMap<std::pair<StringRef, StringRef>> so that we
can look things up quickly. There is some amount of cost to setting up
the map the first time it is called, but subsequent lookups should be
as fast as a hash + string comparison (the cost of looking up something
in an llvm::StringMap).

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

This is an attempt to reduce the time taken by the Bootstrapping
build job and the Clang CI job that builds the compiler from scratch.

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

This uses the same logic as in c2b256a9;
we can't check defined(_MSC_VER) invoked as %clang_cc1, therefore
check for !defined(__MINGW32__) instead.

This fixes the same issue in a new testcase that was added after this
issue was fixed last time in c2b256a9.

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