We can now express all marshalling semantics in `Opt{In,Out}FFlag` via `BoolFOption`.

This patch moves remaining `Opt{In,Out}FFlag` instances using marshalling to `BoolFOption` and removes marshalling capabilities from `Opt{In,Out}FFlag` entirely.

This simplifies the decisions developers have to make when creating new boolean options:
  * For simple cc1 flag pairs, use `Bool{,F,G}Option`.
  * For cc1 flag pairs that require complex marshalling logic, use `Opt{In,Out}FFlag` and implement marshalling manually.

Reviewed By: dexonsmith

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

This patch introduces a tablegen multiclass called `MarshallingInfoEnum`. It has the same semantics as `MarshallingInfoString` had in combination with `AutoNormalizeEnum`, but it's easier to use and follows the convention used for other `MarshallingInfoXxx` multiclasses.

Reviewed By: dexonsmith

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

This fixes the documentation emitted for type parameters. Also adds a
missing empty line, rendered as line break in mark down.

Co-authored-by: Simon Camphausen <simon.camphausen@iml.fraunhofer.de>

Reviewed By: rriddle

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

Hopefully it would be useful for new developers.

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

Fix the logic to find the app bundle in a path by correctly accounting
for paths containing multiple occurrences of `.app`. The new logic will
correctly extract `com.app.Foo.app` from `com.app.Foo.app/com.app.Foo`.

rdar://74666208

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

There are two preconditions to reproduce the issue,
 1. Use -save-temps option
 2. Provide the -o option with name equal to the input file name
    without the file extension. For e.g. clang a.c -o a

With the -o specified, the AssembleJobAction after OffloadWrapperJobAction
will produce the object file with same name as host code object file.
Due to this clash, the OffloadWrapperAction overwrites the initial host
object file, which results in lld error. This also fixes the `multiple definition of __dummy.omp_offloading.entry'` issue in D96769 .

Reviewed By: jdoerfert

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

A SDLoc and XLenVT were already created above the switch.

This document was originally introduced in ab464850, and was reverted in
912bc498 while I investigated a number of shpinx bot errors. This commit
reintroduces the document with fixes for those errors, as well as some
improvements to the wording and formatting.

In the existing logic, we look at the lifetime.start marker of each alloca, and check all uses of the alloca, to see if any pair of the lifetime marker and an use of alloca crosses suspension point.
This approach is unfortunately incorrect. An use of alloca does not need to be a direct use, but can be an indirect use through alias.
Only checking direct uses can miss cases where indirect uses are crossing suspension point.
This can be demonstrated in the newly added test case 007.
In the test case, both x and y are only directly used prior to suspend, but they are captured into an alias, merged through a PHINode (so they couldn't be materialized), and used after CoroSuspend.
If we only check whether the lifetime starts cross suspension points with direct uses, we will put the allocas to the stack, and then capture their addresses in the frame.

Instead of fixing it in D96441 and D96566, this patch takes a different approach which I think is better.
We still checks the lifetime info in the same way as before, but with two differences:
1. The collection of liftime.start is moved into AllocaUseVisitor to make the logic more concentrated.
2. When looking at lifetime.start and use pairs, we not only checks the direct uses as before, but in this patch we check all uses collected by AllocaUseVisitor, which would include all indirect uses through alias. This will make the analysis more accurate without throwing away the lifetime optimization.

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

`-Wreturn-std-move-in-c++11` has been removed in fbee4a0c.

Reviewed By: aaronpuchert, amccarth

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

This patch removes OpaqueAttr as it is no longer used.

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

Move the remaing of FIR types to TableGen type definition. This follow suggestion in D96422.

Reviewed By: schweitz, jeanPerier, rriddle

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

We're running into undefined references using ThinLTO with -O0 on
Windows/Chrome. This fixes that.

This matches the legacy PM.

Reviewed By: tejohnson

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

Adding support for intrinsics of AMX-BF16.
This patch alse fix a bug that AMX-INT8 instructions will be selected with wrong
predicate.

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

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

Reviewed by: Matt Arsenault

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

Add availability checks to the os_signpost code so this can be used with
an older deployment target.

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

(followup to 8472fa6c )

We always create the VL operand using a register, but if we can
determine that it came from an ADDI X0, imm with a sufficiently
small immediate, we can use VSETIVLI.

Reviewed By: frasercrmck

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

We just started using a ComplexPattern for sexti32. This updates
zexti32 to match.

Reviewed By: luismarques

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

For -fgpu-rdc mode, static device vars in different TU's may have the same name.
To support accessing file-scope static device variables in host code, we need to give them
a distinct name and external linkage. This can be done by postfixing each static device variable with
a distinct CUID (Compilation Unit ID) hash.

Since the static device variables have different name across compilation units, now we let
them have external linkage so that they can be looked up by the runtime.

Reviewed by: Artem Belevich, and Jon Chesterfield

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

This expands the op to support error propagation and also makes it symmetric with  "shape.get_extent" op.

Reviewed By: silvas

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

Fix a buffer overrun that can occur when parsing '%c' at the end of a
filename pattern string.

rdar://74571261

Reviewed By: kastiglione

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

This reverts commit 341889ee.

The new unit tests fail on sanitizer-windows.

This relands commit rG7f9d5d6e which was reverted in rGab5b00ad

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

Define inline versions of __compiler_rt_fmax* and __compiler_rt_scalbn*
rather than depend on the versions in libm. As with
__compiler_rt_logbn*, these functions are only defined for single,
double, and quad precision (binary128).

Fixes PR32279 for targets using only these FP formats (e.g. Android
on arm/arm64/x86/x86_64).

For single and double precision, on AArch64, use __builtin_fmax[f]
instead of the new inline function, because the builtin expands to the
AArch64 fmaxnm instruction.

Reviewed By: MaskRay

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

Make sure to set the bottom bit of the symbol even when the type
attribute of a label is set after the label.

GNU as sets the thumb state according to the thumb state of the label.
If a .type directive is placed after the label, set the symbol's thumb
state according to the thumb state of the .type directive. This matches
GNU as in most cases.

From: Stefan Agner <stefan@agner.ch>

This fixes:
https://bugs.llvm.org/show_bug.cgi?id=44860
https://github.com/ClangBuiltLinux/linux/issues/866

Reviewed By: MaskRay

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

This reverts commit 80f329bc.

This extends b40fde06 for the especially non-standard
powi pattern. We want to avoid being completely wrong
on the negation-of-int-min corner case, so I'm adding
an extra FMF check for 'ninf' assuming that gives us
the flexibility to handle that possibility.
https://llvm.org/PR49147

We at least want to add powi to this list, so
split it off into a switch to reduce code duplication.

These should catch any accidental use of the compilation directory.

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

This is a follow up to 22a52dfd and a
revert of df763188.

With this change, we only skip cloning distinct nodes in
MDNodeMapper::mapDistinct if RF_ReuseAndMutateDistinctMDs, dropping the
no-longer-needed local helper `cloneOrBuildODR()`.  Skipping cloning in
other cases is unsound and breaks CloneModule, which is why the textual
IR for PR48841 didn't pass previously. This commit adds the test as:
Transforms/ThinLTOBitcodeWriter/cfi-debug-info-cloned-type-references-global-value.ll

Cloning less often exposed a hole in subprogram cloning in
CloneFunctionInto thanks to df763188's
test ThinLTO/X86/Inputs/dicompositetype-unique-alias.ll. If a function
has a subprogram attachment whose scope is a DICompositeType that
shouldn't be cloned, but it has no internal debug info pointing at that
type, that composite type was being cloned. This commit plugs that hole,
calling DebugInfoFinder::processSubprogram from CloneFunctionInto.

As hinted at in 22a52dfd's commit
message, I think we need to formalize ownership of metadata a bit more
so that ValueMapper/CloneFunctionInto (and similar functions) can deal
with cloning (or not) metadata in a more generic, less fragile way.

This fixes PR48841.

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

Metadata::ImplicitCode is a bit shaved off of Metadata::Storage,
currently only in use by the subclass DILocation. However, the bit isn't
reserved for that purpose. Rename it `SubclassData1` to make it clear
that it has nothing to do with Metadata itself (and other subclasses are
free to use it).

As a drive-by, remove an old TODO about exposing bits to subclasses
(looks like that has mostly been done).

No functionality change here.

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

Reviewed By: arsenm

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

This should allow running tests with the interpreter in some of the
default paths where Python for Windows might be installed.

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