With recent MSVC releases, STL headers will add /INFERASANLIBS to the drectve section of object files that are compiled with clang. With this flag, link.exe will automatically attempt to look for asan libs.

When using clang as the driver to invoke the linker, we want to disable this feature because we explicitly pass the proper asan libraries, otherwise we get symbols defined multiple times.

Reviewed By: hans

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

Part of https://discourse.llvm.org/t/rfc-switching-the-llvm-dialect-and-dialect-lowerings-to-opaque-pointers/68179

The 'use-opaque-pointers' options, when enabled, changes the patterns to emit opaque pointers instead of typed pointers. As part of the migration effort the test have been converted to typed pointers, with an extra file for testing just typed pointers specific code paths.

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

This reverts commit 6b0cf1e1.

The included test is timing out on Arm/AArch64 bots.

Part of https://discourse.llvm.org/t/rfc-switching-the-llvm-dialect-and-dialect-lowerings-to-opaque-pointers/68179

All passes required for lowering have already been successfully converted to allowing opaque-pointers. Switching the Spir-V runner to opaque-pointers is therefore only a matter of turning it on in these conversion passes. Regression tests also did not find any issues.

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

Part of https://discourse.llvm.org/t/rfc-switching-the-llvm-dialect-and-dialect-lowerings-to-opaque-pointers/68179

This patch adds the new pass option 'use-opaque-pointers' to `-launch-func-to-vulkan` instructing the pass to emit LLVM opaque pointers instead of typed pointers.

Note that the pass as it was previously implemented relied on the fact LLVM pointers carried an element type. The passed used this information to deduce both the rank of a "lowered-to-llvm" MemRef as well as the element type. Since the element type when using LLVM opaque pointers is completely erased it is not possible to deduce the element type.

I therefore added a new attribute that is attached to the `vulkanLaunch` call alongside the binary blob and entry point name by the `-convert-gpu-launch-to-vulkan-launch` pass. It simply attaches a type array specifying the element types of each memref. This way the `-launch-func-to-vulkan` can simply read out the element type from the attribute.
The rank can still be deduced from the auto-generated C interface from `FinalizeMemRefToLLVM`. This is admittedly a bit fragile but I was not sure whether it was worth the effort to also add a rank array attribute.

As a last step, the use of opaque-pointers in `mlir-vulkan-runners` codegen pipeline was also enabled, since all covnersion passes used fully support it.

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

Add configuration to specify macros.
Macros will be expanded, and the code will be parsed and annotated
in the expanded state. In a second step, the formatting decisions
in the annotated expanded code will be reconstructed onto the
original unexpanded macro call.

Eventually, this will allow to remove special-case code for
various macro options we accumulated over the years in favor of
one principled mechanism.

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

Postponed from D139433 until the bug fixed by D139874 could be resolved.

Reviewed By: arsenm

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

Previously, the FastmathFlagsInterface has been added twice to
the LLVM::PowIOp. Once directly and once indirectly using the
requiresFastmath flag. This revision only uses the flag and drops
the redundant interface.

Reviewed By: definelicht

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

In Codeview, the basic type of a complex represents the size
of an individual component rather than the sum of the real
and imaginary components.

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

We hit this in Chromium builds where the PDB file was just under 4GB,
but the stream directory was actually too large to be correctly
represented.

llvm-pdbutil would error about this in llvm::msf::validateSuperBlock,
but lld should not write such PDB files in the first place.

Differential revision: https://reviews.llvm.org/D144385

[mlir][Vector][Trivial] Move a conversion to LLVM test to the conversion passes test directory and port it to opaque pointers

Part of https://discourse.llvm.org/t/rfc-switching-the-llvm-dialect-and-dialect-lowerings-to-opaque-pointers/68179

Given this is only a test pass I believe it should be fine to switch it to opaque-pointers entirely while migrating.

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

While the pass itself doesn't directly require any changes to be compatible with opaque-pointers, it does import patterns for lowering MemRefs to LLVM.
Adding this pass option allows any users of the pass to switch to emitting opaque-pointers via the pass option

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

Summary:
A previous patch got rid of the use of this image but forgot to remove
it from this function. Simply remove it as it is unused now.

The contents of these files have been implemented for at least two releases, so let's remove them according to our policy (https://libcxx.llvm.org/DesignDocs/ExperimentalFeatures.html#id4).

Reviewed By: Mordante, #libc

Spies: arichardson, libcxx-commits

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

capget() and capset() may read or write more than one cap_user_data_t,
depending on the version field of cap_user_header_t. Currently the
code assumes it's just one, so MSan complains if an application uses
version 2 or 3, where two cap_user_data_ts are used.

Parse the header in order to determine the number of cap_user_data_ts.
Also add a test.

Reviewed By: vitalybuka

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

This addresses the issue found by:
https://lab.llvm.org/buildbot/#/builders/30/builds/32299

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

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

This reverts commit a9a19501.

The legacy PM uses in Polly have been removed, so recommit the patch.

Original message:
    This is part of the optimization pipeline, of which the legacy pass manager version is deprecated.

    Reviewed By: aeubanks

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

This patch implements the exception handling rules found in
N4849 14.4 and as a result fixes many false positives in
the bugprone-exception-escape checker.

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

The pass uses a bunch of deprecated legacy passes and appears unused.
Remove it to unblock removing legacy passes.

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

Reviewed By: Meinersbur

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

This reverts commit 5a4f193a.

See https://reviews.llvm.org/D144673, this change broke multiple
buildbots.

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

Not sure this is the right place for it next to the table.

This carries a bitmask indicating forbidden floating-point value kinds
in the argument or return value. This will enable interprocedural
-ffinite-math-only optimizations. This is primarily to cover the
no-nans and no-infinities cases, but also covers the other floating
point classes for free. Textually, this provides a number of names
corresponding to bits in FPClassTest, e.g.

  call nofpclass(nan inf) @must_be_finite()
  call nofpclass(snan) @cannot_be_snan()

This is more expressive than the existing nnan and ninf fast math
flags. As an added bonus, you can represent fun things like nanf:

  declare nofpclass(inf zero sub norm) float @only_nans()

Compared to nnan/ninf:
  - Can be applied to individual call operands as well as the return value
  - Can distinguish signaling and quiet nans
  - Distinguishes the sign of infinities
  - Can be safely propagated since it doesn't imply anything about
    other operands.
  - Does not apply to FP instructions; it's not a fl...

A BTI instruction was previously inserted at the beginning of each block
that has its address stored in a jump table. Jump tables only emit
indirect jumps in ARM or Thumb1 modes. However, PACBTI is not supported
in these modes. As a result, BTI instructions emitted by jump tables are
redundant. Removing redundant BTI instructions improves the code size
and prevents potential gadgets.

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

Some memory instructions in the following sections of Armv7-M ARM allow
the .w mnemonic suffix, even though the preferred disassembly is without
the suffix.

A7.7.46 LDRB (immediate) T3
A7.7.55 LDRH (immediate) T3
A7.7.59 LDRSB (immediate) T2
A7.7.63 LDRSH (immediate) T2
A7.7.163 STRB (immediate) T3
A7.7.170 STRH (immediate) T3

This patch accepts the .w suffixes for theses instructions.
Pseudo-instructions and custom parsing logic are used instead of simple
aliases. More discussions are in these relevant patches:
https://reviews.llvm.org/D68916
https://reviews.llvm.org/D96632

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

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

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

getMemBufferCopy triggers an UB when it receives a default constructed
StringRef. Make sure that we're always passing the null-terminated string
created in ParseInputs throughout the scanPreamble.

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

Fixes https://github.com/clangd/clangd/issues/1484

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

This allows users to specify a  top-down or bottom-up traversal of the IR, in addition to the already existing WalkOrder.

Certain transformations work better with a forward traversal. E.g., when cloning a piece of IR, operations should be cloned top-down so that all uses are defined when creating an op.

Certain transformations work better with a reverse traversal. E.g., when erasing a piece of IR, operations should be erased bottom-up to avoid erasing operations that still have users.

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

This should fix the regressions introduced by a53d940c by making
sure no dynamic allocations are needed in the common case, while
retaining support for arbitrary SCEV expressions.

Alternative to D144335.

Compile-time impact:
* NewPM-O3: -0.11%
* NewPM-ReleaseThinLTO: -0.10%
*NewPM-ReleaseLTO-g: -0.08%

https://llvm-compile-time-tracker.com/compare.php?from=df016a9525e5722dfd1e1e1632cec3ed7b33bc8a&to=c1c64de4a973bcecaddbc4038a539234eb39413b&stat=instructions:u

Reviewed By: vitalybuka, nikic

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

Abstract derived-type components can have default value so perform
the default value initialization if necessary.

```
type, abstract :: a
  integer :: b = 10
end type

type, extends(a) :: b
  integer :: d
end type
```

Reviewed By: klausler

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

Enable character and derived type array constructor lowering.
Nothing special needs to be done other than lowering the types
before the array constructor lowering.
Derived type are forced to use the runtime for now to avoid
undesired usage of user defined assignment that hlfir.assign
may trigger when using the runtime.

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

This is recommit of 2e416cdd, fixed to be accepatble by GCC.
The original commit message is below.

With this change bitwise operations are allowed for FPClassTest
enumeration, it must simplify using this type. Also some functions
changed to get argument of type FPClassTest instead of unsigned.

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

Lower the cases that require runtime support to deal
with the allocation, reallocation, or copy of ac-values to
the array constructor storage.

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