Without this patch, we pass Endian as one of the parameters to the
constructor of DWARFDataExtractor.  The problem is that Endian is of:

  enum endianness {big, little, native};

whereas the constructor is expecting "bool IsLittleEndian".  That is,
we are relying on an implicit conversion to convert big and little to
false and true, respectively.

When we migrate llvm::support::endianness to std::endian in future, we
can no longer rely on an implicit conversion because std::endian is
declared with "enum class".  Even if we could, the conversion would
not be guaranteed to work because, for example, libcxx defines:

  enum class endian {
    little = 0xDEAD,
    big = 0xFACE,
    :

where big and little are not boolean values.

This patch fixes the problem by properly converting Endian to a
boolean value.

Without this patch, we pass G.getEndianness() as one of the parameters
to DWARFContext::create.  The problem is that G.getEndianness() is of:

  enum endianness {big, little, native};

whereas DWARFContext::create is expecting "bool isLittleEndian".  That
is, we are relying on an implicit conversion to convert big and little
to false and true, respectively.

When we migrate llvm::support::endianness to std::endian in future, we
can no longer rely on an implicit conversion because std::endian is
declared with "enum class".  Even if we could, the conversion would
not be guaranteed to work because, for example, libcxx defines:

  enum class endian {
    little = 0xDEAD,
    big = 0xFACE,
    :

where big and little are not boolean values.

This patch fixes the problem by properly converting G.getEndianness()
to a boolean value.

This patch updates AffineParallelOp::verify() to check each result type matches
its corresponding reduction op (i.e, the result type must be a `FloatType` if
the reduction attribute is `addf`)

affine.parallel will crash on --lower-affine if the corresponding result type
cannot match the reduction attribute.

```
      %128 = affine.parallel (%arg2, %arg3) = (0, 0) to (8, 7) reduce ("maxf") -> (memref<8x7xf32>) {
        %alloc_33 = memref.alloc() : memref<8x7xf32>
        affine.yield %alloc_33 : memref<8x7xf32>
      }
```
This will crash and report a type conversion issue when we run `mlir-opt --lower-affine`

```
Assertion failed: (isa<To>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file Casting.h, line 572.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.	Program arguments: mlir-opt --lower-affine temp.mlir
 #0 0x0000000102a18f18 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/workspacebin/mlir-opt+0x1002f8f18)
 #1 0x0000000102a171b4 llvm::sys::RunSignalHandlers() (/workspacebin/mlir-opt+0x1002f71b4)
 #2 0x0000000102a195c4 SignalHandler(int) (/workspacebin/mlir-opt+0x1002f95c4)
 #3 0x00000001be7894c4 (/usr/lib/system/libsystem_platform.dylib+0x1803414c4)
 #4 0x00000001be771ee0 (/usr/lib/system/libsystem_pthread.dylib+0x180329ee0)
 #5 0x00000001be6ac340 (/usr/lib/system/libsystem_c.dylib+0x180264340)
 #6 0x00000001be6ab754 (/usr/lib/system/libsystem_c.dylib+0x180263754)
 #7 0x0000000106864790 mlir::arith::getIdentityValueAttr(mlir::arith::AtomicRMWKind, mlir::Type, mlir::OpBuilder&, mlir::Location) (.cold.4) (/workspacebin/mlir-opt+0x104144790)
 #8 0x0000000102ba66ac mlir::arith::getIdentityValueAttr(mlir::arith::AtomicRMWKind, mlir::Type, mlir::OpBuilder&, mlir::Location) (/workspacebin/mlir-opt+0x1004866ac)
 #9 0x0000000102ba6910 mlir::arith::getIdentityValue(mlir::arith::AtomicRMWKind, mlir::Type, mlir::OpBuilder&, mlir::Location) (/workspacebin/mlir-opt+0x100486910)
...
```

Fixes #64068

Reviewed By: mehdi_amini

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

Prior to 591c4b64, the mingw specific
linker options -mthreads, -mconsole, -mwindows and -mdll would be
tolerated also at compile time, but generating a warning about being
unused.

After that commit, they were marked as target specific, which means that
it's an error if they're unused (which would consider them used for the
wrong target). These specific options are only relevant when linking,
but we want to tolerate them at compile time too, like before.

This was fixed for -mthreads in
a79995ca, while the other options didn't
seem to be commonly used during compilation.

After the 17.x release, we've got more reports about this actually being
an issue, in #64464. Therefore, apply the same fix for them; marking
them as tolerated for mingw targets during compilation, even if they're
unused. Also add a testcase for -mthreads which was already handled.

Thus, this fixes #64464.

Without this patch, we pass Endian as one of the parameters to the
constructor of DataExtractor.  The problem is that Endian is of:

  enum endianness {big, little, native};

whereas the constructor is expecting "bool IsLittleEndian".  That is,
we are relying on an implicit conversion to convert big and little to
false and true, respectively.

When we migrate llvm::support::endianness to std::endian in future, we
can no longer rely on an implicit conversion because std::endian is
declared with "enum class".  Even if we could, the conversion would
not be guaranteed to work because, for example, libcxx defines:

  enum class endian {
    little = 0xDEAD,
    big = 0xFACE,
    :

where big and little are not boolean values.

This patch fixes the problem by properly converting Endian to a
boolean value.

Check that the number of retained operands and updated conditions match.

This broke build bots.

[DAG] Extend the computeOverflowForSignedSub/computeOverflowForUnsignedSub implementations with ConstantRange (#67890)

- Add tests for computeOverflowFor*Sub functions
- extend the computeOverflowForSignedSub/computeOverflowForUnsignedSub
implementations with ConstantRange (#37109)

We could maybe extend this by allowing the lowest subop to have multiple uses and extract the lowest subvector result of the concatenated op, but let's just get the fix in first.

Fixes #67333

When custom install names and rpaths setups are used they may not
work in the build tree as-is (namely when using absolute paths for
install names in order to avoid rpath juggling in downstream projects).

Add a flag for opting out of this behaviour.

See: https://reviews.llvm.org/D42463

Without this, various CodeGen tests fail because a
RISCV::FCVT_D_W[_IN32X] machine node is created without the rounding
mode operand.

The relevant PR was committed as bf94ba39

[RISCV][MC] Fix all remaining fcvt instructions that didn't accept rounding mode but should have (#67889)

This is a follow-up to #67555, performing the same fix for the other
instructions that had this issue:
* fcvt.d.w
* fcvt.d.wu
* fcvt.s.h
* fcvt.d.h

As before, we stick to the 'rne' default because this gives maximum
compatibility with older LLVM and GNU tools when disassembling. I've
also double checked disassembling fp-default-rounding-mode.s with GNU
objdump to re-confirm it uses frm=0b000 for these instructions.

This avoids some redundant spills of subranges, and avoids a compile failure.
This greatly reduces the numbers of spills in a loop.

The main range is not informative when multiple instructions are needed to fully define
a register. A common scenario is a lowered reg_sequence where every subregister
is sequentially defined, but each def changes the main range's value number. If
we look at specific lanes at the use index, we can see the value is actually the
same.

In this testcase, there are a large number of materialized 64-bit constant defs
which are hoisted outside of the loop by MachineLICM. These are feeding REG_SEQUENCES,
which is not considered rematerializable inside the loop. After coalescing, the split
constant defs produce main ranges with an apparent phi def. There's no phi def if you look
at each individual subrange, and only half of the register is really redefined to a constant.

Fixes: SWDEV-380865

https://reviews.llvm.org/D147079

SplitKit creates questionably formed bundles of copies
when it needs to copy a subset of live lanes and can't do
it with a single subregister index. These are merely marked
as part of a bundle, and don't start with a BUNDLE instruction.
Queries for the slot index would give the first copy in the
bundle, and we need to inspect the operands of all the other
bundled copies.

Also fix and simplify detection of read lane subsets. This causes
some RISCV test regressions, but these look like accidentally beneficial
splits. I don't see a subrange based reason to perform these splits.

Avoids some really ugly regressions in a future patch.

https://reviews.llvm.org/D146859

https://reviews.llvm.org/D152789 added an `exit` op before each
`unreachable`. This means we never get to the `trap` instruction.

This change limits the insertion of `exit` instructions to the cases
where `unreachable` is not lowered to `trap`. Trap itself is changed to
be emitted as `trap; exit;` to convey to `ptxas` that it exits the CFG.

This will make it possible to add visibility attributes to these
variables.  This also fixes some type mismatches between the
declaration and the definition.

Reviewed By: bogner, huangjd

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

C:\buildbot\mlir-x64-windows-ninja\llvm-project\llvm\lib\Object\MachOUniversalWriter.cpp(352) : error C2220: the following warning is treated as an error
C:\buildbot\mlir-x64-windows-ninja\llvm-project\llvm\lib\Object\MachOUniversalWriter.cpp(352) : warning C4715: 'llvm::object::writeUniversalBinaryToStream': not all control paths return a value

Followup to #67628 that relaxes the symbol regex a bit to cover more
lldb_private symbols.

/llvm-project/llvm/lib/Object/MachOUniversalWriter.cpp:351:3: error: default label in switch which covers all enumeration values [-Werror,-Wcovered-switch-default]
  default:
  ^
1 error generated.

Xcode `lipo` seems to support a non-documented `-fat64` option that
creates Universal Mach-O archives using 64 bit versions of the
`fat_arch` header, which allows offsets larger than 32 bits to be
specified.

Modify `llvm-lipo` to support the same flag, and use the value of the
flag to use either 32 bits or 64 bits Mach-O headers.

The Mach-O universal writer allows specifying a new option to write
these 64 bits headers. The default is still using 32 bits.

`dsymutil` implemented support for a similar flag in
https://reviews.llvm.org/D146879.

This seems to be an issue common to both GCC and LLVM. There are various
RISC-V FCVT instructions where the frm field makes no difference to the
output as the result is always exact (e.g. fcvt.d.s, fcvt.s.h,
fcvt.d.h). As with GCC, we always generate a form of these fcvt
instructions where frm=0b000. However, the ISA manual _doesn't_ state
that frm values are invalid, and we should ensure we can accept them.
This patch does so by adding the frm field to fcvt.d.s and adding an
InstAlias so that if no frm is specified, it defaults to rne (0b000).

This patch just corrects fcvt.d.s in order to allow the approach to be
reviewed, before applying it to the other affected instructions.

I haven't added tests to llvm/test/MC/Disassembler/RISCV, because it
doesn't seem necessary to test there in addition to our usual round-trip
tests in llvm/test/MC/RISCV. But feedback is welcome.

Recently added tests ensure that the default `rne` rounding mode is
printed as desired.

These are not available in all build configurations.

Originally introuduced in: https://github.com/llvm/llvm-project/pull/66430

This reverts commit 16b9e6fb.

This breaks buildbots.

This adds `IntegralAP` backing the two new primtypes `IntAP` (unsigned
arbitrary-precision int) and `IntAPS` (same but signed).

We use this for `int128` support (which isn't available on all host
systems we support AFAIK) and I think we can also use this for `_BitInt`
later.

See discourse thread https://discourse.llvm.org/t/rfc-support-cmake-option-to-control-link-type-built-for-flang-runtime-libraries/71602/18 for full details.

Flang-rt is the new library target for the flang runtime libraries. It builds the Flang-rt library (which contains the sources of FortranRuntime and FortranDecimal) and the Fortran_main library. See documentation in this patch for detailed description (flang-rt/docs/GettingStarted.md).

This patch aims to:
- integrate Flang's runtime into existing llvm infrasturcture so that Flang's runtime can be built similarly to other runtimes via the runtimes target or via the llvm target as an enabled runtime
- decouple the FortranDecimal library sources that were used by both compiler and runtime so that different build configurations can be applied for compiler vs runtime
- add support for running flang-rt testsuites, which were created by migrating relevant tests from `flang/test` and `flang/unittest` to `flang-rt/test` and `flang-rt/unittest`, using a new `check-flang-rt` target.
- provide documentation on how to build and use the new FlangRT runtime

Reviewed By: DanielCChen

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

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

LLVMGetOrdering previously did not support Fence instructions, and
calling it on a fence would lead to a bad cast as it
assumed a load/store, or an AtomicRMWInst. This would either read a
garbage memory order, or assertion

LLVMIsAtomicSingleThread did not support either Fence instructions,
loads, or stores, and would similarly lead to a bad cast.
It happened to work out since the relevant types all have their synch
scope ID at the same offset, but it still should be fixed

These cases are now fixed for the C API, and tests for these
instructions are added. The echo test utility now also supports cloning
Fence instructions, which it did not previously

-----

From what I can tell, there's no unified API to pull
`getOrdering`/`getSyncScopeID` from, and instead requires casting to
individual types: if there is a better way of handling this I can s...

The newly added tests check which rounding mode is used by default, and
that it is printed when aliases are disabled but not otherwise.

These tests will be used in #67555.

* Remove if its sole use is to support an unnecessary ptr-to-ptr bitcast
  (remove the bitcast as well)
* Replace with use of other APIs.

NFC opaque pointer cleanup effort.

* Remove if its sole use is to support an unnecessary ptr-to-ptr bitcast
  (remove the bitcast as well)
* Replace with use of other APIs.

NFC opaque pointer cleanup effort.

The AArch64StorePairSuppress pass prevents the creation of STP under some
heuristics. Unfortunately it often prevents the creation of STP in cases where
it is obviously beneficial, and it doesn't match my understanding of
scheduling/cpu pipelining to prevent the creation of STP. From some
benchmarking, even on an in-order cpu where the scheduling is most important I
don't see it giving better results. In general the lower instruction count for
STP would be expected to give a slightly better cycle count.

As the pass specifically mentions the cyclone cpu, this patch adds a target
feature for FeatureStorePairSuppress, enabled for all the non-Arm cpus. This
has the effect of disabling it for all Arm cpus.

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

To do this:
1. Protect BC.Ctx with mutex
2. Don't call exit from thread, please check the reason comment near
PassFailed variable definition. The other option would be call _Exit
instead of exit, but I think we shall call destructors properly.

Most of the print options are hidden, make hidden them all.

It always returns false in the unwrapped line parser!

After patch https://github.com/llvm/llvm-project/pull/67288 landed,
unfoldMemoryOperand would not return NewMIs whose size ==3. So the
removed line is useless.

This patch replaces any_cast with llvm::any_cast. This in turn allows
us to gracefully switch to std::any in future by forwarding llvm::Any
and llvm::any_cast to:

  using Any = std::any;

  template <class T> T *any_cast(Any *Value) {
    return std::any_cast<T>(Value);
  }

respectively.

Without this patch, it's ambiguous whether any_cast refers to
std::any_cast or llvm::any_cast.

As an added bonus, this patch makes it easier to mechanically replace
llvm::any_cast with std::any_cast without affecting other occurrences of
any_cast (e.g. in libcxx).