see D118852 for matching hwasan fix.

Reviewed By: eugenis

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

This is a tool which can handle bitstream and YAML remarks. The idea here is to
provide more insight into which functions changed in a benchmark when testing
compiler changes.

E.g. "foo got 20% bigger, so maybe we should look more closely at that."

To use the tool, you can use...

```
$ llvm-remark-size-diff remarks_file_a remarks_file_b --parser=yaml|bitstream
```

... on two remarks files containing at least instruction count remarks. This
will output some data on instruction count change and also other relevant
information such as stack size change from `remarks_file_a` to `remarks_file_b`.

This is a bit of a WIP so I'm happy to change the format etc. Ultimately I think
it'd be best to have some JSON output which could be consumed by another tool.
But some base-level, greppable output is very handy to have anyway.

The format I'm proposing here is

```
<files> <inc/dec in inst count> <fn name> <inst count change> <stack B change>
```

Where the files and increase/decrease are indicated like below:

- `<files>` is one of `++` (file B), `--` (file A), `==` (both)
- `<inc/dec in inst count>` is one of `>` (increase) or `<` (decrease)

This makes it easy to grep for things like "which functions appeared in A but
did not appear in B?" Or "what are all the instruction count decreases?"

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

we will also need this for aarch64 stack tagging.

Reviewed By: eugenis

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

In a future change, we will sometimes use a VGPR offset for doing
spills to memory, in which case we need 2 free VGPRs to do the SGPR
spill. In most cases we could spill the VGPR along with the SGPR being
spilled, but we don't have any free lanes for SGPR_1024 in wave32 so
we could still potentially need a second scavenging slot.

Test a range of acceptable forms of co_broadcast calls, including
combinations of keyword and non-keyword actual arguments of
intrinsic and derived type.  Also test that several invalid forms
of co_sum call generate the correct error messages.

Reviewed By: ktras

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

In the case your framework bundles contain relocatable objects, and your
objects include LC_LINKER_OPTIONs for the framework, previously they
would not be deduplicated like they would have if they were static
archives. This was also the case if you passed `-framework` for the
framework as well.

Reviewed By: #lld-macho, thakis, oontvoo

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

EHTerminateScope is used to implement C++ noexcept semantics. Per C++
[except.terminate], it is implemented-defined whether no, some, or all
cleanups are run prior to terminatation.

Therefore, the code to run cleanups on the way towards termination is
unnecessary, and may be omitted.

After this change, we will still run some cleanups: any cleanups in a
function called from the noexcept function will continue to run, while
those in the noexcept function itself will not.

(Commit attempt 2: check InnermostEHScope != stable_end() before accessing it.)

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

This is completely unused upstream, and does not really have well defined semantics
on what this is supposed to do/how this fits into the ecosystem. Given that, as part of
splitting up the standard dialect it's best to just remove this behavior, instead of try
to awkwardly fit it somewhere upstream. Downstream users are encouraged to
define their own operations that clearly can define the semantics of this.

This also uncovered several lingering uses of ConstantOp that weren't
updated to use arith::ConstantOp, and worked during conversions because
the constant was removed/converted into something else before
verification.

See https://llvm.discourse.group/t/standard-dialect-the-final-chapter/ for more discussion.

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

The Utils.cpp file in StandardOps essentially just contains utilities for interacting with arithmetic
operations, and at this point makes more sense as a utility file for the arithemtic dialect.

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

This is part of splitting up the standard dialect. See https://llvm.discourse.group/t/standard-dialect-the-final-chapter/ for discussion.

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

This is part of the larger effort to split the standard dialect. This will also allow for pruning some
additional dependencies on Standard (done in a followup).

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

Reviewed By: eugenis

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

This variable was added to `InstrProfWriter.cpp`  in D115693 by mistake and it isn't needed.

Reviewed By: kyulee

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

Summery:
  Fix a few typos in docs AMDGPUUsage.rst

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

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

Instead of using the (now deprecated) Projects build for libcxx, libcxxabi,
libunwind and compiler-rt, this patch uses the Bootstrapping build. This
implies that Clang will be built from scratch, and then the runtimes will
be built using that just-built Clang instead of the system compiler.
This is the correct way of assembling a toolchain, since we don't want
to ship runtimes that were built with a non-Clang compiler (or a
potentially older Clang).

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

Simplifies the code slightly.

Reviewed By: #lld-macho, thakis

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

As noted in D116804, we want to effectively invert that patch
for CPUs (intel) that don't break the false dependency on
sbb %eax, %eax

So we will likely want to create that here in the
X86DAGToDAGISel::Select() case for X86::SETCC_CARRY.

setjmp can return twice, but PostDominatorTree is unaware of this. as
such, it overestimates postdominance, leaving some cases where memory
does not get untagged on return. this causes false positives later in
the program execution.

this is a workaround for now, in the longer term PostDominatorTree
should be made aware of returns_twice, as this may cause problems
elsewhere.

See D118647 for equivalent fix to HWASan.

Reviewed By: eugenis

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

When a mode flag is modified (e.g., BLANK='ZERO') in an I/O data transfer
statement, ensure that the right set of mode flags is modified.
There's one set of mode flags that are captured by an OPEN
statement and maintained in the connection, and another that
is maintained in an I/O statement state record for local mutability.
Some I/O API routines were unconditionally modifying the persistent
set of flags.

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

The verifier field is deprecated, and slated for removal.

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

The verifier field is deprecated, and slated for removal.

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

The verifier field is deprecated, and slated for removal.

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

The verifier field is deprecated, and slated for removal.

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

The verifier field is deprecated, and slated for removal.

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

The verifier field is deprecated, and slated for removal.

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

The verifier field is deprecated, and slated for removal.

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

The verifier field is deprecated, and slated for removal.

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

The verifier field is deprecated, and slated for removal.

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

The verifier field is deprecated, and slated for removal.

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

Currently if an operation requires additional verification, it specifies an inline
code block (`let verifier = "blah"`). This is quite problematic for various reasons, e.g.
it requires defining C++ inside of Tablegen which is discouraged when possible, but mainly because
nearly all usages simply forward to a static function `static LogicalResult verify(SomeOp op)`.
This commit adds support for a `hasVerifier` bit field that specifies if an additional verifier
is needed, and when set to `1` declares a `LogicalResult verify()` method for operations to
override. For migration purposes, the existing behavior is untouched. Upstream usages will
be replaced in a followup to keep this patch focused on the hasVerifier implementation.

One main user facing change is that what was one `MyOp::verify` is now `MyOp::verifyInvariants`.
This better matches the name this method is called everywhere else, and also frees up `verify` for
the user defined additional verification. The `verify` function when generated now (for additional
verification) is private to the operation class, which should also help avoid accidental usages after
this switch.

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

- note that `split_view` has been renamed to `lazy_split_view`.
- fix formatting.

Also refactor tests for `indirectly_movable{,_storable}`.

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

this is so we can use it for aarch64 stack tagging.

Reviewed By: eugenis

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