This allows to define custom splitters, which is interesting for
non-MLIR inputs and outputs to `mlir-translate`. For example, one may
use `; -----` as a splitter of `.ll` files. The splitters are now passed
as arguments into `splitAndProcessBuffer`, the input splitter defaulting
to the previous default (`// -----`) and the output splitter defaulting
to the empty string, which also corresponds to the previous default. The
behavior of the input split marker should not change at all; however,
outputs now have one new line *more* than before if there is no splitter
(old: `insertMarkerInOutput = false`, new: `outputSplitMarker = ""`) and
one new line *less* if there is one. The value of the input splitter is
exposed as a command line options of `mlir-translate` and other tools as
an optional value to the previously existing flag `-split-input-file`,
which defaults to the default splitter if not specified; the value of
the output splitter is exposed with the new `-output-split-marker`,
which default to the empty string in `mlir-translate` and the default
splitter in the other tools. In short, the previous usage or omission of
the flags should result in previous behavior (modulo the new lines
mentioned before).

Revert 4fef8c75 "[X86] splitVectorOp - share the same SDLoc argument instead of recreating it over and over again."

This appears to have broken the clang-with-thin-lto-ubuntu buildbot somehow (unconfirmed but its a likely candidate)

Remove Expensive option copy and delete copy assignment

Blocking that signal causes inter-blocking for profilers that monitor
threads through that signal.
Fix #83844 and #83561

mlir/include/mlir/Target/Cpp/CppEmitter.h:27:45: error: unknown type name 'raw_ostream'; did you mean 'llvm::raw_ostream'?
   27 | LogicalResult translateToCpp(Operation *op, raw_ostream &os,
      |                                             ^~~~~~~~~~~
      |                                             llvm::raw_ostream

[Support] KnownBitsTest - don't bother creating lambdas in testBinaryOpExhaustive callbacks if we can just use the raw KnownBits/APIntOps function reference. NFCI.

This patch changes DPValue::filter to be a non-member method
filterDbgVars. There are two reasons for this: firstly, the name of
DPValue is about to change to DbgVariableRecord, which will result in
every `for` loop that uses DPValue::filter to require a line break. This
is a small thing, but it makes the rename patch more difficult to
review, and is just generally more awkward for what is a fairly common
loop. Secondly, the intent is to later break up the DPValue class into
subclasses, at which point it would be better to have a non-member
function that allows template arguments for the cases we want to filter
with greater specificity.

Perform the requested arithmetic and produce a carry output in addition
to the normal result.

Clang has them as builtins (__builtin_add_overflow_p). The middle end
has intrinsics for them (sadd_with_overflow).

AArch64: ADDS Add and set flags

On Neoverse V2, they run at half the throughput of basic arithmetic and
have a limited set of pipelines.

It's useful to provide an indicator code with the trap, which the generic
__builtin_trap can't do. asm("brk #N") is an option, but following that with a
__builtin_unreachable() leads to two traps when the compiler doesn't know the
block can't return. So compiler support like this is useful.

This patch adds some small updates to the LLVM documentation regarding
DbgRecords to accurately describe the current class structure. There are
some more refactorings to come, so this isn't intended to be the final
document update, but it covers the immediate task of updating references
to DPValue that really refer to DbgRecord.

Update AnyOf reduction code generation to only keep track of the AnyOf
property in a boolean vector in the loop, only selecting either the new
or start value in the middle block.

The patch incorporates feedback from https://reviews.llvm.org/D153697.

This fixes the #62565, as now there aren't multiple uses of the
start/new values.

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

PR: https://github.com/llvm/llvm-project/pull/78304

This also moves `tuple_size_v` into `tuple_size` as a drive-by.

Add support for the WebAssembly binary format and be able to generate
logical views.

https://github.com/llvm/llvm-project/issues/69181

The README.txt includes information about how to build the test cases.

Supports both signed and unsigned expansions.

SelectionDAG now calls the APInt implementation of these functions.

Fixes #84211.

This PR adds type inference of function parameters by call instances.
Two use cases that demonstrate the problem are added.

Another instance where we produce an instruction that defines a vreg
with an i32 value.

I noticed a failure of [running LLDB test suites on Windows
AArch64](https://lab.llvm.org/buildbot/#/builders/219/builds/9849). The
failed test case is about
checking output of command `breakpoint list -v -L c++`, and an mismatch
on the demangled
name of a function occurred. The test case expects `ns::func(void)`, but
on Windows it is `int ns::func(void)`.
It results from the different mangling scheme used by MSVC, and the
comparison is as follows:

| Scheme | Mangled | Demangled (fully) | Note |
| --- | --- | --- | --- |
| MSVC | `?func@ns@@YAHXZ` | `int __cdecl ns::func(void)` |
[Godbolt](https://godbolt.org/z/5ns8c7xW3) (I have no available Windows
device) |
| Itanium | `_ZN2ns4funcEv` | `ns::func()` | |

According to the current use of MSVC demangling,


https://github.com/llvm/llvm-project/blob/8f68022f8e6e54d1aeae4ed301f5a015963089b7/lldb/source/Core/Mangled.cpp#L128-L143

the `__cdecl` specifier is not part of the name. However, the function's
parameter types should be present
as ` llvm::MSDF_NoVariableType` [does not affect a symbol for
functions](https://github.com/llvm/llvm-project/blob/8f68022f8e6e54d1aeae4ed301f5a015963089b7/llvm/lib/Demangle/MicrosoftDemangleNodes.cpp#L417-L453).

Therefore, it is inappropriate to assume the demangled name are the same
on all platforms. Instead of tweaking the
existing code of demangling to get the same (demangled) name, I think it
is more reasonable to modify the test case.

StaticAnalyzer didn't check if the variable is declared in
`CompoundStmt` under `SwitchStmt`, which make static analyzer reach root
without finding the declaration.

Fixes #68819

---------

Co-authored-by: Balazs Benics <benicsbalazs@gmail.com>

[C++20] [Modules] [Reduced BMI] Generate the function body from implicitly instantiated class and constant variables

After this patch, we will generate the function body from implicitly
instantiated class. This is important for consumers with same
template arguments. Otherwise the consumers won't see the function body.
Since the consumers won't instantiate the templates again if they find an
instantiation.

Also we will generate the variable definition if the variable is
non-inline but known as constant. Such variables may not affect the
ABI, but they may get involved into the compile time constant computation
in the consumer's code. So we have to generate such definitions.

When converting complex.sqrt op to standard, we need to keep the fast
math flag given to the op.

See:
https://discourse.llvm.org/t/rfc-fastmath-flags-support-in-complex-dialect/71981

[MLIR][Bufferization] BufferResultsToOutParams: Add option to add attribute to output arguments (#84320)

Adds a new pass option `add-result-attr` that will make the pass add the
attribute `{bufferize.result}` to each argument that was converted from
a result.
This is important e.g. when later using the python bindings / execution
engine to understand which arguments are actually results.

To be able to test this, the pass option was added to the tablegen. To
avoid collisions with the existing, manually defined option struct
`BufferResultsToOutParamsOptions`, that one was renamed to
`BufferResultsToOutParamsOpts`.

Removes linking and registering dialects that are not support any more.

Try to fix https://github.com/llvm/llvm-project/issues/84368


When visiting class members in
`TemplateDeclInstantiator::VisitClassTemplateDecl` during
`Sema::InstantiateClass`, we miss to set attribute of friend declaration
if it is(`isFriend` is true). This will lead to
`Sema::AreConstraintExpressionsEqual` return false when invoked in
`MatchTemplateParameterKind`. Because it makes
`Sema::getTemplateInstantiationArgs` returns incorrect template
argument(`MultiLevelTemplateArgumentList`). When we handle
`CXXRecordDecl` In `Sema::getTemplateInstantiationArgs`, friend
declaration(its parent context is `FileContext`) makes us to choose
`LexicalDeclContext` not `DeclContext` and this is what we want.

Co-authored-by: huqizhi <836744285@qq.com>

This patch canonicalizes `extractvalue (select Cond, TV, FV)` into
`select Cond, (extractvalue TV), (extractvalue FV)`. The latter form may
enable more optimizations.

Previously, clang-dxc.exe would not recognize -HV as a valid argument to
DXC, and would be unable to translate the argument to a legal clang
argument. This PR implements a translation of the HV option and its
value to the appropriate clang flag and the appropriate value. It adds a
test by using the -### option to spit out the translated options, and
checks to see that the correct option was generated.
Fixes #83479

---------

Co-authored-by: Chris B <cbieneman@microsoft.com>

[RISCV] Move matchRegisterNameHelper into the RISCVAsmParser and remove IsRVE argument. NFC (#85172)

With it in the class we can use isRVE() inside the function instead of
making the callers do it.

For convenience, add an additional constructor to `RewriterBase` and
`IRRewriter` that also sets the insertion point. `OpBuilder` provides a
similar constructor.

isAccessIndexInvariant had outdated code and didn't handle IR with
multiple
affine.apply ops, which is inconvenient when used as a utility.  This is
addressed by switching to use the proper API on AffineValueMap. Add
mlir::affine::isInvariantAccess exposed for outside use and tested via
the test pass. Add a method on AffineValueMap.  Add test cases to
exercise simplification and composition for invariant access analysis.

A TODO/FIXME has been added but this issue existed before.

For Embedded Swift, let's unblock building for RISC-V boards (e.g.
ESP32-C6). This isn't trying to add full RISC-V support to Swift /
Embedded Swift, it's just fixing the immediate blocker (not having
SwiftInfo defined blocks all compilations).

The `ConceptReference`'s `FoundDecl` claims it "can differ from
`NamedConcept` when, for example, the concept was found through a
`UsingShadowDecl`", but such the contract was not previously respected.

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