Make core BOLT functionality more friendly to being used as a
library instead of in our standalone driver llvm-bolt. To accomplish
this, we augment BinaryContext with journaling streams that are to be
used by most BOLT code whenever something needs to be logged to the
screen. Users of the library can decide if logs should be printed to a
file, no file or to the screen, as before. To illustrate this, this
patch adds a new option --log-file that allows the user to redirect
BOLT logging to a file on disk or completely hide it by using
--log-file=/dev/null. Future BOLT code should now use
BinaryContext::outs() for printing important messages instead of
llvm::outs(). A new test log.test enforces this by verifying that no
strings are print to screen once the --log-file option is used.

We also refactor old error handling code that would directly call
exit(1) inside BOLT libraries whenever a serious problem occurred. To
overcome this, we add a new class BOLTError and auxiliary functions
createFatalBOLTError() and createNonFatalBOLTError() that allows BOLT
libs to bubble up the problem to the caller by using the Error class
as a return type (or Expected). To easily handle problems as before
(by quitting with exit(1)), callers can now use
BinaryContext::logBOLTErrorsAndQuitOnFatal(Error) whenever code needs
to deal with BOLT errors. To test this, we have fatal.s that checks
we are correctly quitting and printing a fatal error to the screen.

Because this is a significant change by itself, not all code was yet
ported. Code from Profiler libs (DataAggregator and friends) still
print errors directly to screen.

debugserver will not compress small packets; the overhead of the
compression header makes this useful for larger packets. I default to
384 bytes in debugserver, and added an option for lldb to request a
different cutoff. This option has never been used in lldb in the past
nine years, so I don't think there's any point to keeping it around.

This handles two cases where we can work out some known-zero bits for
ISD::STEP_VECTOR.

The first case handles when we know the low bits are zero because the
step
amount is a power of two. This is taken from
https://reviews.llvm.org/D128159

,
and even though the original patch didn't end up landing this case due
to it
not having any test difference, I've included it here for completeness's
sake.

The second case handles the case when we have an upper bound on
vscale_range.
We can use this to work out the upper bound on the number of elements,
and thus
what the maximum step will be. From the maximum step we then know which
hi bits
are zero.

On its own, computing the known hi bits results in some small
improvements for
RVV with -mrvv-vector-bits=zvl across the llvm-test-suite. However I'm
hoping
to be able to use this later to reduce the LMUL in index calculations
for
vrgather/indexed accesses.

---------

Co-authored-by: Philip Reames <preames@rivosinc.com>

Currently, __builtin_return_address is used to generate the return
address when the callback invoker is created. However, this may result
in the return address pointing to an internal runtime function. This is
not what a tool would typically want. A tool would want to know the
corresponding user code from where the runtime entry point is invoked.

This change adds a thread local variable that is assigned the return
address at the OpenMP runtime entry points. An RAII is used to manage
the modifications to the thread local variable. Whenever the return
address is required for OMPT events, it is read from the thread local
variable.

Libunwind supports FP64 and FP32 modes, but not FPXX. The reason is
that, FP64 and FP32 have different way to save/restore FPRs. If
libunwind is built as FPXX, we have no idea which one should we use.

It's not due to the code bug, but rather the nature of FPXX.
FPXX is an ABI which uses only a common subset of FR=1(FP64) and FR=0
(FP32).
So that FPXX binaries can link with both FP64 and FP32 ones, aka.
    FPXX + FP32 -> FP32
    FPXX + FP64 -> FP64

While for libunwind, we should save/restore all of FPRs. If we use FPXX,
we can only save/restore a common subset of FPRs, instead of superset.

If libunwind is built as FP64, it will interoperatable with FPXX/FP64
APPs, and if it is built as FP32, it will interoperatable with
FP32/FPXX. Currently most of O32 APPs are FPXX or FP64, while few are
FP32.

So if the compiler is FPXX, which is the default value of most
toolchain, let's switch it to FP64.

Co-authored-by: YunQiang Su <yunqiang.su@cipunited.com>

Missed in #80937 since it's not currently being used.

Basic block sections "all" doesn't work on AArch64 since branch
relaxation may create new basic blocks. However, the other basic
block section modes should work out of the box since machine function
splitting already uses the basic block sections pass.

* they all do stack adjustments, so they all use and def x2.
* popret and popretz also return
* popretz also defines x10

This adds that to the TD file and updates the PushPopOptimizer to
preserve the extra implicit operands added during frame lowering when
converting to popret(z).

mach-o object files never have separate debug info, and in a big app
there can be quite a large number of object files, so even a few stats
per object file can slow launches considerably.
This patch avoids this search for Mach-o symbol files of object type.

I don't have a way to test this, the only effect is that you didn't do a
bunch of stats that weren't going to do any good anyway.

The MachineFunctionAnalysisManager forward declaration is messing with upcoming changes.

The call to the inlining utility does not update the call graph. Leading
to assertion failures when calling the call graph utility to update the
call graph.

Instead rely on an inline pass to run after coro splitting and use
alwaysinline annotations.

github.com/apple/swift/issues/68708

Some profiling showed that the accesses to this map during bitcode
reading was incurring over 10% of the time in a large thin link. There
is no need for it to be std::map, and I measured around 8.5% time
reduction in the same thin link from switching to DenseMap.

This is only used in assert statement.

[flang] Introducing a method to dynamically and conditionally register dialect interfaces.  (#80881)

This change introduces the `addFIRExtensions` method to dynamically and
conditionally register dialect interfaces. As a use case of
`addFIRExtensions`, this change moves the static registration of
`FIRInlinerInterface` out of the constructor of `FIROpsDialect` to be
dynamically registered while loading the necessary MLIR dialects
required by Flang. This registration of `FIRInlinerInterface` is also
guarded by a boolean `addFIRInlinerInterface` which defaults to true.

---------

Co-authored-by: Vijay Kandiah <vkandiah@nvidia.com>

This patch flips bit-fields in `struct flags` for big-endian in test
cases to be consistent with the definition of the structure in libomp
`kmp.h`.

The changeset extends LLVMIR intrinsics with VCIX intrinsics.
The VCIX intrinsics allow MLIR users to interact with RISC-V
co-processors that are compatible with `XSfvcp` extension

Source:
https://www.sifive.com/document-file/sifive-vector-coprocessor-interface-vcix-software

Reapply the original commit, 0aacd44a, which had a missing brace resulting in
an error in compilation.

This reverts commit c76b0eb8.

Wasm has no unified virtual memory space as other object formats and
architectures do, so previously WasmObjectFile reported 0 for all
section addresses, and until 428cf71f used section offsets for function
symbols. Now we use file offsets for function symbols, and this change
switches section addresses to do the same (in linked files). The main
result of this is that objdump now reports VMAs in section listings, and
also uses file offets rather than section offsets when disassembling
linked binaries (matching the behavior of other disassemblers and stack
traces produced by browwsers). To make this work, this PR also updates
objdump's generation of synthetics fallback symbols to match lib/Object
and also correctly plumbs symbol types for regular and dummy symbols
through to the backend to avoid needing special knowledge of address 0.

This also paves the way for generating symbols from name sections rather
than symbol tables or imports (see #76107) by allowing the
disassembler's synthetic fallback symbols match the name-section
generated symbols (in a followup PR).

I found a bug in `test-compose-subview`,You can see the example I gave.
```
#map = affine_map<() -> ()>
module {
  func.func private @fun(%arg0: memref<10x10xf32>, %arg1: memref<5x5xf32>) -> memref<5x5xf32> {
    %c0 = arith.constant 0 : index
    %c5 = arith.constant 5 : index
    %c1 = arith.constant 1 : index
    %subview = memref.subview %arg0[0, 0] [5, 5] [1, 1] : memref<10x10xf32> to memref<5x5xf32, strided<[10, 1]>>
    %alloc = memref.alloc() : memref<5x5xf32>
    scf.for %arg2 = %c0 to %c5 step %c1 {
      scf.for %arg3 = %c0 to %c5 step %c1 {
        %subview_0 = memref.subview %subview[%arg2, %arg3] [1, 1] [1, 1] : memref<5x5xf32, strided<[10, 1]>> to memref<f32, strided<[], offset: ?>>
        %subview_1 = memref.subview %arg1[%arg2, %arg3] [1, 1] [1, 1] : memref<5x5xf32> to memref<f32, strided<[], offset: ?>>
        %alloc_2 = memref.alloc() : memref<f32>
        linalg.generic {indexing_maps = [#map, #map, #map], iterator_types = []} ins(%subview_0, %subview_1 : memref<f32, strided<[], offset: ?>>, memref<f32, strided<[], offset: ?>>) outs(%alloc_2 : memref<f32>) {
        ^bb0(%in: f32, %in_4: f32, %out: f32):
          %0 = arith.addf %in, %in_4 : f32
          linalg.yield %0 : f32
        }
        %subview_3 = memref.subview %alloc[%arg2, %arg3] [1, 1] [1, 1] : memref<5x5xf32> to memref<f32, strided<[], offset: ?>>
        memref.copy %alloc_2, %subview_3 : memref<f32> to memref<f32, strided<[], offset: ?>>
      }
    }
    return %alloc : memref<5x5xf32>
  }
  func.func @test(%arg0: memref<10x10xf32>, %arg1: memref<5x5xf32>) -> memref<5x5xf32> {
    %0 = call @fun(%arg0, %arg1) : (memref<10x10xf32>, memref<5x5xf32>) -> memref<5x5xf32>
    return %0 : memref<5x5xf32>
  }
}
```
When I run `mlir-opt test.mlir ---test-compose-subview`.
```
test.mlir:14:9: error: 'linalg.generic' op expected operand rank (2) to match the result rank of indexing_map #0 (0)
        linalg.generic {indexing_maps = [#map, #map, #map], iterator_types = []} ins(%subview_0, %subview_1 : memref<f32, strided<[], offset: ?>>, memref<f32, strided<[], offset: ?>>) outs(%alloc_2 : memref<f32>) {
        ^
test1.mlir:14:9: note: see current operation: 
"linalg.generic"(%4, %5, %6) <{indexing_maps = [affine_map<() -> ()>, affine_map<() -> ()>, affine_map<() -> ()>], iterator_types = [], operandSegmentSizes = array<i32: 2, 1>}> ({
^bb0(%arg4: f32, %arg5: f32, %arg6: f32):
  %8 = "arith.addf"(%arg4, %arg5) <{fastmath = #arith.fastmath<none>}> : (f32, f32) -> f32
  "linalg.yield"(%8) : (f32) -> ()
}) : (memref<1x1xf32, strided<[10, 1], offset: ?>>, memref<f32, strided<[], offset: ?>>, memref<f32>) -> ()
```
This PR fixes that.In the meantime I've extended this PR to handle cases
where stride is greater than 1.
```
func.func private @Unknown0(%arg0: memref<10x10xf32>, %arg1: memref<5x5xf32>) -> memref<5x5xf32> {
  %c0 = arith.constant 0 : index
  %c5 = arith.constant 5 : index
  %c1 = arith.constant 1 : index
  %subview = memref.subview %arg0[0, 0] [5, 5] [2, 2] : memref<10x10xf32> to memref<5x5xf32, strided<[20, 2]>>
  %alloc = memref.alloc() : memref<5x5xf32>
  scf.for %arg2 = %c0 to %c5 step %c1 {
    scf.for %arg3 = %c0 to %c5 step %c1 {
      %subview_0 = memref.subview %subview[%arg2, %arg3] [1, 1] [1, 1] : memref<5x5xf32, strided<[20, 2]>> to memref<f32, strided<[], offset: ?>>
      %subview_1 = memref.subview %arg1[%arg2, %arg3] [1, 1] [1, 1] : memref<5x5xf32> to memref<f32, strided<[], offset: ?>>
      %alloc_2 = memref.alloc() : memref<f32>
      linalg.generic {indexing_maps = [affine_map<() -> ()>, affine_map<() -> ()>, affine_map<() -> ()>], iterator_types = []} ins(%subview_0, %subview_1 : memref<f32, strided<[], offset: ?>>, memref<f32, strided<[], offset: ?>>) outs(%alloc_2 : memref<f32>) {
      ^bb0(%in: f32, %in_4: f32, %out: f32):
        %0 = arith.addf %in, %in_4 : f32
        linalg.yield %0 : f32
      }
      %subview_3 = memref.subview %alloc[%arg2, %arg3] [1, 1] [1, 1] : memref<5x5xf32> to memref<f32, strided<[], offset: ?>>
      memref.copy %alloc_2, %subview_3 : memref<f32> to memref<f32, strided<[], offset: ?>>
    }
  }
  return %alloc : memref<5x5xf32>
}
$ mlir-opt test.mlir -test-compose-subview
#map = affine_map<()[s0] -> (s0 * 2)>
#map1 = affine_map<() -> ()>
module {
  func.func private @Unknown0(%arg0: memref<10x10xf32>, %arg1: memref<5x5xf32>) -> memref<5x5xf32>  {
    %c0 = arith.constant 0 : index
    %c5 = arith.constant 5 : index
    %c1 = arith.constant 1 : index
    %alloc = memref.alloc() : memref<5x5xf32>
    scf.for %arg2 = %c0 to %c5 step %c1 {
      scf.for %arg3 = %c0 to %c5 step %c1 {
        %0 = affine.apply #map()[%arg2]
        %1 = affine.apply #map()[%arg3]
        %subview = memref.subview %arg0[%0, %1] [1, 1] [2, 2] : memref<10x10xf32> to memref<f32, strided<[], offset: ?>>
        %subview_0 = memref.subview %arg1[%arg2, %arg3] [1, 1] [1, 1] : memref<5x5xf32> to memref<f32, strided<[], offset: ?>>
        %alloc_1 = memref.alloc() : memref<f32>
        linalg.generic {indexing_maps = [#map1, #map1, #map1], iterator_types = []} ins(%subview, %subview_0 : memref<f32, strided<[], offset: ?>>, memref<f32, strided<[], offset: ?>>) outs(%alloc_1 : memref<f32>) {
        ^bb0(%in: f32, %in_3: f32, %out: f32):
          %2 = arith.addf %in, %in_3 : f32
          linalg.yield %2 : f32
        }
        %subview_2 = memref.subview %alloc[%arg2, %arg3] [1, 1] [1, 1] : memref<5x5xf32> to memref<f32, strided<[], offset: ?>>
        memref.copy %alloc_1, %subview_2 : memref<f32> to memref<f32, strided<[], offset: ?>>
      }
    }
    return %alloc : memref<5x5xf32>
  }
}
```

Implement the following assembly format flags, which are already
supported by GCC:

	'A': On z14 or higher: If operand is a mem print the alignment
         hint usable with vl/vst prefixed by a comma.
	'O': print only the displacement of a memory reference or address.
	'R': print only the base register of a memory reference or address.

Implement 'A' conservatively, since the memory operand alignment
information is not available for INLINEASM at the moment.

Fixes : #69085 , #69200

**PR SUMMARY**: "Added Null check for negative sized array and a test
for the same"

Reland the original patch with additional commit containing fix for two
issues:

1. Attempting to bitcast using MVTs with no corresponding LLVM type.
getDWordFromOffset now works directly with the original vector to get
the corresponding elements given the DWordOffset.
2. Improper bit tracking in CalculateByteProvider for vector types using
certain ops. Previously, bit tracking for certain ops (e.g.
ISD::TRUNCATE) assumed operands were scalar types, which is not correct
since these ops have different semantics depending on vector / scalar.
CalculateByteProvider / CalculateSrcByte now exit on vector types,
handling which is a TODO.

This PR adds a direct vectorization lowering of `tensor.pack` into
`mask(vector.transfer_read)`->`vector.shape_cast`->`vector.transpose`->`vector.transfer_write`.

This removes 3 dead function decls from mlir-opt:
- registerTestLowerToNVVM - recently removed in #75775 when NVVM was
  productized.
- registerTestPreparationPassWithAllowedMemrefResults - removed in
  D90778 (f7bc5682).
- registerTestGenericIRVisitorsInterruptPass - added in D116230
  (8067ced1) but never existed. Pass is registered by
  registerTestGenericIRVisitorsPass.

Fix for assert after PR#78264.

Handle the case where the MIB context is empty after skipping the
callsite context, because the callsite context is actually longer than
the MIB context. Presumably this happened as a result of inlining, but
in theory the metadata should have been replaced with an attribute in
that case. Need to investigate why this is occuring, but for now handle
this gracefully to fix the build regression.

Reference: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2612.pdf.

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

The MergeFunctions pass has a "preserve some debug-info" mode that tries
to preserve parameter values. This patch generalises its decision-making
so that it applies to both debug-info stored in intrinsics, and
debug-info stored in DPValue objects. For the most part this involves
using a generic lambda and applying it to each type of object.

(Normally we avoid debug-info affecting the code generated, but this is
hidden behind a command line switch, so won't usually be encountered by
users).

Note that this diff is messy, but that's because I'm hoisting some code
into lambdas. The actual decision making processes here are identical.

OpFlag and WrapperKind should be chosen consistently with each other in
regards to PIC, otherwise we hit asserts later on.

Broken by c04a05d8.

Fixes #80831.

With the legacy pass manager, MachineModuleInfoWrapperPass owned the
MachineModuleInfo used in the codegen pipeline. It can do this since
it's an ImmutablePass that doesn't get invalidated.

However, with the new pass manager, it is legal for the
ModuleAnalysisManager to clear all of its analyses, regardless of if the
analysis does not want to be invalidated. So we must move ownership of
the MachineModuleInfo outside of the analysis (this is similar to
PassInstrumentation). For now, make the PassBuilder user register a
MachineModuleAnalysis that returns a reference to a MachineModuleInfo
that the user owns. Perhaps we can find a better place to own the
MachineModuleInfo to make using the codegen pass manager less cumbersome
in the future.

This patch removes some bitwise folds that fail to check the one-use
constraint on the operands.
See also the comments
https://github.com/llvm/llvm-project/pull/77231#issuecomment-1904090035.

This was broken by 1a642606.

[Flang] Use specific symbol rather than generic symbol as procInterface to declare procedure pointer. (#80738)

Flang crashes when lowering the type of `p1` with the following code.
The problem is when it sets up the `procInterface`, it uses the generic
symbol `int`, not the specific `int`. This PR is to correct that.

```
  INTERFACE Int
    integer FUNCTION Int(arg)
      integer :: arg
    END FUNCTION
  END INTERFACE

  integer :: res
  procedure(int), pointer :: p1
  p1 => int
  res = p1(4)
  end
  ```