There are two ways to interrupt flang when a TODO is hit: abort or
exit with non-zero exit code. Abort implies printing the backtrace
and "PLEASE submit a bug report" message. We used to use abort
only in debug compiler build. Since the TODOs are already known
problems it may be counterproductive to ask debug compiler users
to submit bug reports. In addition, the TODO messages are pretty
self-explanatory, so the backtrace printing seems to be redundant.

This change makes all TODOs non-aborting. I added TODO_.*TRACE macros
for TODOs that may benefit from the backtrace and the "bug report"
message in the debug compiler. These macros are currently unused.

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

This reverts commit b296ddd9.

This reverts commit f889d6f9.

Also, since it is only used in two tests that are C++11/C++14 tests only,
I don't think it is worth keeping around in test_allocator.h.

In reality this would have always been fine because main's
stack frame will always be live when another thread is
executing the cc1_reproducer_main. But ASan and HWASan
were upset

This commit adds support for a new callback-based lookup scheme for unwind
info that was inspired by the `_dyld_find_unwind_info_sections` SPI that
libunwind uses to find unwind-info in non-JIT'd frames. From
llvm-project/libunwind/src/AddressSpace.hpp:

```
struct dyld_unwind_sections {
  const struct mach_header*   mh;
  const void*                 dwarf_section;
  uintptr_t                   dwarf_section_length;
  const void*                 compact_unwind_section;
  uintptr_t                   compact_unwind_section_length;
};

extern bool _dyld_find_unwind_sections(void *, dyld_unwind_sections *);
```

During unwinding libunwind calls `_dyld_find_unwind_sections` to both find
unwind section addresses and identify the subarchitecture for frames (via the
MachO-header pointed to by the mh field).

This commit introduces two new libunwind SPI functions:

```
struct unw_dynamic_unwind_sections {
  unw_word_t dso_base;
  unw_...

Don't use the ldrd instruction; that one requires armv5te. Instead
do two separate loads (or only one if OMPT_SUPPORT isn't defined).

This should fix https://github.com/llvm/llvm-project/issues/60370.

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

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

These are similar to hardware registers already added for GFX940,
but with different numbers and slightly different names.

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

Add TOSA f64 type support for cast op

Reviewed By: eric-k256

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

See https://github.com/llvm/llvm-project/issues/57475 for more context.

Using auto-generated constructors and options has significant advantages:
* It forces a uniform style and expectation for consuming a pass
* It allows to very easily add, remove or change options to a pass by simply making the changes in TableGen
* Its less code

This patch in particular ports all the conversion passes which lower to LLVM to use the auto generated constructors and options. For the most part, care was taken so that auto generated constructor functions have the same name as they previously did. Only following slight breaking changes (which I consider as worth the churn) have been made:
* `mlir::cf::createConvertControlFlowToLLVMPass` has been moved to the `mlir` namespace. This is consistent with basically all conversion passes
* `createGpuToLLVMConversionPass` now takes a proper options struct array for its pass options. The pass options are now also autogenerated.
* `LowerVectorToLLVMOptions` has been replaced by the autogenerated `ConvertVectorToLLVMPassOptions` which is automatically kept up to date by TableGen
* I had to move one function in the GPU to LLVM lowering as it is used as default value for an option.
* All passes that previously returned `unique_ptr<OperationPass<...>>` now simply return `unique_ptr<Pass>`

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

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

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

D100808 implemented the new version, but kept version 1 as the
emitted version. This patch changes the version to 2 and updates the
codegen tests.

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

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

Summary:
  This is part of the leftover work for https://reviews.llvm.org/D143138.
In this work, we pass code object version as an argument to initialize target ID
and use it for targetID dump.

Reviewers: arsenm

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

If the modifiedType and the minimally desugared type of an AttributedType are the same, then we do not need to show both in an AST dump.

Here, we change VisitAttributedType to only visit the modifiedType when it is different from the equivalentType (the minimally desugared type), because the latter is already visited by default.

Reviewed By: sammccall

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

Previously, when performing a reduction on a sparse tensor, the result
would be different depending on iteration order. For expanded access pattern,
an empty row would contribute no entry in the output. For lex ordering, the
identity would end up in the output.

This code changes that behavior and keeps track of whether any entries were
actually reduced in lex ordering, making the output consistent between the
two iteration styles.

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

Properly set floating point exceptions and add more exceptional
values for non-FMA x86-64 targets.

Reviewed By: michaelrj

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

Fixes #55869

Reviewed By: njames93, nicovank

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

Also make expected mangling more flexible since it's different
between Linux and Darwin

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

Namely CrossDSOCFI and GlobalSplit.

These are part of the optimization pipeline, of which the legacy pass manager version is deprecated.

Fuzzing the string to integer and float functions without relying on the
system libc allows for tests to be run in a wider variety of places.

Reviewed By: sivachandra

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

The revert of
  https://reviews.llvm.org/rG65f9719913eca9c7c72d1abf4eddab767abaebf6

removes a system-windows guard but does not remove the test causing windows
system failures. This patch adds back a guard to prevent further failures.

Removes a reference to google-internal document and expands the relevant material in place.

Fixes: #60633.

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

Without this patch, migrateDebugInfo doesn't understand how to handle existing
fragments that are smaller than the to-be-split store. This can occur
if. e.g. a vector store (1 dbg.assign) is split (many dbg.assigns - 1 fragment
for each scalar) and later those stores are re-vectorized (many dbg.assigns),
and then SROA runs on that.

The approach taken in this patch is to drop intrinsics with fragments outside
of the slice.

For example, starting with:

  store <2 x float> %v, ptr %dest !DIAssignID !1
  call void @llvm.dbg.assign(..., DIExpression(DW_OP_LLVM_fragment, 0, 32), !1, ...)
  call void @llvm.dbg.assign(..., DIExpression(DW_OP_LLVM_fragment, 32, 32), !1, ...)

When visiting the slice of bits 0 to 31 we get:

  store float %v.extract.0, ptr %dest !DIAssignID !2
  call void @llvm.dbg.assign(..., DIExpression(DW_OP_LLVM_fragment, 0, 32), !2, ...)

The other dbg.assign associated with the currently-split store is dropped for
this split part. And visiting bits 32 to 63 we get the following:

  store float %v.extract.1, ptr %adjusted.dest !DIAssignID !3
  call void @llvm.dbg.assign(..., DIExpression(DW_OP_LLVM_fragment, 32, 32), !3, ...)

I've added two tests that cover this case.

Implementing this meant re-writing the fragment-calculation part of
migrateDebugInfo to work with the absolute offset of the new slice in terms of
the base alloca (instead of the offset of the slice into the new alloca), the
fragment (if any) of the variable associated with the base alloca, and the
fragment associated with the split store. Because we need the offset into the
base alloca for the variables being split, some careful wiring is required for
memory intrinsics due to the fact that memory intrinsics can be split when
either the source or dest allocas are split. In the case where the source
alloca drives the splitting, we need to be careful to pass migrateDebugInfo the
information in relation to the dest alloca.

Reviewed By: StephenTozer

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

The mid end will reassociate sub(sub(x, m1), m2) to sub(x, add(m1, m2)). This
reassociates it back to allow the creation of more mls instructions.

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

operator~ promote the single bit input to int. The ~ will cause the upper
31 bits to become 1s making it a negative value. This is undefined for
shift.

Mask it back down to a single bit.

The extra 1s were being shifted to bit 8 and above and the they aren't
used by the emitByte call so this shouldn't be a functional change.

Even if liveness changed, we only care about certain dead edges in
AAIntraFnReachability. If those are still dead, we can avoid an update.

If a query uses an exclusion set but we haven't used it to determine the
result, we can cache the query without exclusion set too. When we lookup
a cached result we can check for the non-exclusion set version first.

This caused multiple string operations which we don't need if we do not
create a profile.

This change simply avoids the temporary vector and processes the elments
right away.