Precise string layout has changed a lot recently, but a long of these
changes did not have any effect on the usages of its fields -- e.g.
introduction/removal of an anonymous struct or union does not change the
way one can access the field in C++. Our name-based variable lookup
rules (deliberately) copy the C++ semantics, which means these changes
would have been invisible to the them, if only we were using name-based
lookup.

This patch replaces the opaque child index accesses with name-based
lookups, which allows us to greatly simplify the data formatter code.
The formatter continues to support all the string layouts that it
previously supported.

It is unclear why the formatter was not using this approach from the
beginning. I would speculate that the original version was working
around some (now fixed) issue with anonymous members or base classes,
and the subsequent revisions stuck with that approach out of inertia.

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

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

As part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179,
this removes support for the floating-point binop constant expressions
fadd, fsub, fmul, fdiv and frem.

As part of this change, the C APIs LLVMConstFAdd, LLVMConstFSub,
LLVMConstFMul, LLVMConstFDiv and LLVMConstFRem are removed.
The LLVMBuild APIs should be used instead.

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

This is still failing as endianness of binary blob external
resources is still not handled correctly.

https://reviews.llvm.org/D126446 added support for encoding
binary blobs in MLIR assembly.  To enable cross-architecture
compatibility, these need to be encoded in little-endian format.

This patch is a first step in that direction by reading and
writing the alignment tag that those blobs are prefixed by
in little-endian format.  This fixes assertion failures in
several test cases on big-endian platforms.

The actual content of the blob is not yet handled here.

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

When computing the base addresses of an array slice to make a
descriptor, codegen generated two LLVM GEPs. The first to compute
the address of the base character element, and a second one to
compute the substring base inside that element.
The previous code did not care about getting the result of the first
GEP right: it used the base array LLVM type as the result type.
This used to work when opaque pointer were not enabled (the actual GEP
result type was probably applied in some later pass). But with opaque
pointers, the second GEP ends-up computing an offset of len*<LLVM array
type> instead of len*<character width>. A previous attempt to fix the
issue was done in D129079, but it does not cover the cases where the
array slice contains subcomponents before the substring
(e.g: array(:)%char_field(5:10)).

This patch fix the issue by computing the actual GEP result type in
codegen. There is also enough knowledge now so that a single GEP can be
generated instead of two.

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

FirOpBuilder takes a fir::KindMapping reference. When the getKindMapping()
call is made inside the ctor call, the lifetime of this reference may
be as short as the ctor call (at least with when building flang in
release mode with clang 8). This can cause segfaults when later using
the FirOpBuilder.

Ensure the kindMap passed to the FirOpBuilder ctor is the same as the
FirOpBuilder.

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

MacroUnexpander applies the structural formatting of expanded lines into
UnwrappedLines to the corresponding unexpanded macro calls, resulting in
UnwrappedLines for the macro calls the user typed.

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

dot is currently miscompiled for booleans (uses add instead of or).

Reviewed By: bkramer

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

I thought I had already fixed all of these, but I guess I missed one.

As discussed on:
  https://discourse.llvm.org/t/build-llvm-release-bat-script-options/63146/6

Latest 7-zip versions (21.x) require administrator permissions
to create symbolic links.

Check if any of the following conditions is true:
- Version of 7-zip is 20.x or older
- Script is running with administrator permissions

Reviewed By: hans, thieta

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

According to @aaron.ballman this was marked Tentatively Ready as of 2022-07-07.
D129362 implemented the C counterpart.

Reviewed By: ldionne, #libc, Mordante

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

This can be enabled by using a `-re` suffix when defining the expected line,
e.g. `expected-error-re`. This support is similar to what clang provides in its "expected"
diagnostic framework(e.g. the `-re` is also the same). The regex definitions themselves are
similar to  FileCheck in that regex blocks are specified within `{{` `}}` blocks.

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

This patch replaces hasValue with has_value in an effort to deprecate
Optional<X>::hasValue.

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

The last uses were removed on Apr 15, 2022 in commit
2e6ac54c.

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

Reviewed By: nickdesaulniers

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

This reverts commit efbaad1c.
due to miss adding review info.

Summary:
We use the `--host-triple=` argument to manually set the target triple.
This was changed to include the `=` previously but was not included in
these additional test cases, causing it for fail on some unsupported
systems.

Turn off execution of tests that use UNIX-specific features.

Reviewed By: Amir

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

[DependencyScanningTool.cpp] Use `using namespace` instead of wrapping the `.cpp` file contents in namespaces, NFC

This makes the file consistent with the coding style of the rest of LLVM.

Add -experimental-shrink-wrapping flag to control when we
want to move callee-saved registers even when addresses of the stack
frame are captured and used in pointer arithmetic, making it more
challenging to do alias analysis to prove that we do not access
optimized stack positions. This alias analysis is not yet implemented,
hence, it is experimental. In practice, though, no compiler would emit
code to do pointer arithmetic to access a saved callee-saved register
unless there is a memory bug or we are failing to identify a
callee-saved reg, so I'm not sure how useful it would be to formally
prove that.

Reviewed By: Amir

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

Change shrink-wrapping to try a priority list of save
positions, instead of trying the best one and giving up if it doesn't
work. This also increases coverage.

Reviewed By: Amir

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

Add the option to run -equalize-bb-counts before shrink
wrapping to avoid unnecessarily optimizing some CFGs where profile is
inaccurate but we can prove two blocks have the same frequency.

Reviewed By: Amir

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

Refactor isStackAccess() to reflect updates by D126116. Now we only
handle simple stack accesses and delegate the rest of the cases to
getMemDataSize.

Reviewed By: Amir

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

Change how function score is calculated and provide more
detailed statistics when reporting back frame optimizer and shrink
wrapping results. In this new statistics, we provide dynamic coverage
numbers. The main metric for shrink wrapping is the number of executed
stores that were saved because of shrink wrapping (push instructions
that were either entirely moved away from the hot block or converted
to a stack adjustment instruction). There is still a number of reduced
load instructions (pop) that we are not counting at the moment. Also
update alloc combiner to report dynamic numbers, as well as frame
optimizer.

For debugging purposes, we also include a list of top 10 functions
optimized by shrink wrapping. These changes are aimed at better
understanding the impact of shrink wrapping in a given binary.

We also remove an assertion in dataflow analysis to do not choke on
empty functions (which makes no sense).

Reviewed By: Amir

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

Move the constants for printf's return values into core_structs, and
update the converters to match.

Reviewed By: lntue

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

LLDB supports having globbing regexes in the process launch arguments
that will be resolved using the user's shell. This requires that we pass
the launch args to the shell and then read back the expanded arguments
using LLDB's argdumper utility.

As the shell will not just expand the globbing regexes but all special
characters, we need to escape all non-globbing charcters such as $, &,
<, >, etc. as those otherwise are interpreted and removed in the step
where we expand the globbing characters. Also because the special
characters are shell-specific, LLDB needs to maintain a list of all the
characters that need to be escaped for each specific shell.

This patch adds the list of special characters that need to be escaped
for fish. Without this patch on systems where fish is the user's shell
having any of these special characters in your arguments or path to
the binary will cause the process launch to fail. E.g., `lldb -- ./calc
1<2` is failing without this patch. The same happens if the absolute
path to calc is in a directory that contains for example parentheses
or other special characters.

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

Add a test that ensures we always prioritize exact triple matches when
creating platforms. This is a regression test for a (now resolved) bug
that that resulted in the remote tvOS platform being selected for a tvOS
simulator binary because the ArchSpecs are compatible.

Add test that hits the limit introduced in 4796b4ae.

It seems like the `sed` on Windows is not particularly
smart. It's not actually needed in this place, so I've
removed it's usage and just created an invalid yaml
another way.

Only one caller didn't already have an MVT and that was easy to
fix. Since the return type is MVT and it uses MVT::getVectorVT,
taking an MVT as input makes the most sense.

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