When both CUDA or HIP programs and C++ programs are passed
to clang driver without -c, C++ programs are treated as CUDA
or HIP program, which is incorrect.

This is because action builder sets the offloading kind of input
job actions to the linking action to be the union of offloading
kind of the input job actions, i.e. if there is one HIP or CUDA
input to the linker, then all the input to the linker is marked
as HIP or CUDA.

To fix this issue, the offload action builder tracks the originating
input argument of each host action, which allows it to determine
the active offload kind of each host action. Then the offload
kind of each input action to the linker can be determined
individually.

Reviewed by: Artem Belevich

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

We had using namespace std; sprinkled around several source files and tests.

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

When both HIP and C++ programs are input files to clang
with -c, clang treats C++ programs as HIP programs,
which is incorrect.

This is due to action builder does not set correct
offloading kind for job actions for C++ programs.

Reviewed by: Artem Belevich

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

RegionBranchOpInterface and BranchOpInterface are allowed to make implicit type conversions along control-flow edges. In effect, this adds an interface method, `areTypesCompatible`, to both interfaces, which should return whether the types of corresponding successor operands and block arguments are compatible. Users of the interfaces, here on forth, must be aware that types may mismatch, although current users (in MLIR core), are not affected by this change. By default, type equality is used.

`async.execute` already has unequal types along control-flow edges (`!async.value<f32>` vs. `f32`), but it opted out of calling `RegionBranchOpInterface::verifyTypes` in its verifier. That method has now been removed and `RegionBranchOpInterface` will verify types along control edges by default in its verifier.

Reviewed By: rriddle

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

This allows using GTEST_SKIP() to identify un-executed tests.

Found by the Rotten Green Tests project.

Such initializer functions can be enqueued in `BufferizationOptions`. They can be used to set up dialect-specific bufferization state.

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

Fix small bugs in aarch64/EFnvImpl.h and simplify feclearexcept_test.

Reviewed By: sivachandra

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

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

This clarifies that these methods only work in append mode, not for general insertions.  This is a prospective change towards https://github.com/llvm/llvm-project/issues/51652 which also performs random-access insertions, so we want to avoid confusion.

Reviewed By: aartbik

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

LLD (and ld64) emits uppercase hex addresses in the mapfile. The
map-file.s test passes right now because the addresses we emit happen
not to include any alphabets, but that can easily change.

I noticed this while dealing with
https://github.com/llvm/llvm-project/issues/54184.

Reviewed By: #lld-macho, thakis

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

Now all the tests that cover symbol resolution / precedence have
"resolution" in their filename.

I also added a couple of extra comments.

Reviewed By: #lld-macho, thakis

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

This patch filters out callstack frames which can't be symbolized or if
the frames belong to the runtime. Symbolization may not be possible if
debug information is unavailable or if the addresses are from a shared
library. For now we only support optimization of the main binary which
is statically linked to the compiler runtime.

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

Remove the redundant header FPUtil/FEnvUtils.h, use FPUtil/FEnvImpl.h header instead.

Reviewed By: sivachandra

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

This patch fixes a bug introduced in D117887.

Reviewed By: tra

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

The custom state machine had a check for surplus threads that filtered
the main thread if the kernel was executed by a single warp only. We
now first check for the main thread, then for surplus threads, avoiding
to filter the former out.

Fixes #54214.

Reviewed By: jhuber6

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

Revert "[SROA] Maintain shadow/backing alloca when some slices are noncapturnig read-only calls to allow alloca partitioning/promotion"

Bots are reporting that the assertion about only expecting loads is wrong.

This reverts commit 703240c7.

This fixes a warning about comparing mismatched types. Since `mmap()` already returns a `void *` use that as the pointer type for comparison.

Reviewed By: kyulee, zequanwu

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

The idea is that, other parts of the libc which require thread/lock
support will be able to use this platform independent setup.

With this change, only the linux implementation of a mutex type has been
moved to the new library. Because of this, there is some duplication
between the new library and src/threads/linux. A follow up change will
move all of src/threads/linux to the new library. The duplication should
be eliminated with that move.

Reviewed By: lntue

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

This is slightly more user-visible than D119894, because the user is
expected to touch `__wrap_iter` directly. But the affected ctors are
non-public, so the user was never expected to be actually calling them.
And I didn't intentionally omit this from D119894; I just didn't
think of it.

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

Libomptarget uses some shared variables to track certain internal stated
in the runtime. This causes problems when we have code that contains no
OpenMP kernels. These variables are normally initialized upon kernel
entry, but if there are no kernels we will see no initialization.
Currently we load the runtime into each source file when not running in
LTO mode, so these variables will be erroneously considered undefined or
dead and removed, causing miscompiles. This patch temporarily works
around the most obvious case, but others still exhibit this problem. We
will need to fix this more soundly later.

Fixes #54208.

Reviewed By: jdoerfert

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

[SROA] Maintain shadow/backing alloca when some slices are noncapturnig read-only calls to allow alloca partitioning/promotion

This is inspired by the original variant of D109749 by Graham Hunter,
but is a more general version.

Roughly, instead of promoting the alloca, we call it
a shadow/backing alloca, go through all it's slices,
clone(!) instructions that operated on it,
but make them operate on the cloned alloca,
and promote cloned alloca instead.

This keeps the shadow/backing alloca, and all the original instructions
around, which results in said shadow/backing alloca being
a perfect mirror/representation of the promoted alloca's content,
so calls that take the alloca as arguments (non-capturingly!)
can be supported.

For now, we require that the calls also don't modify the alloca's content,
but that is only to simplify the initial implementation,
and that will be supported in a follow-up.

Overall, this leads to *smaller* codesize:
https://llvm-compile-time-tracker.com/compare.php?from=a8b4f5bbab62091835205f3d648902432a4a5b58&to=aeae054055b125b011c1122f82c86457e159436f&stat=size-total
and is roughly neutral compile-time wise:
https://llvm-compile-time-tracker.com/compare.php?from=a8b4f5bbab62091835205f3d648902432a4a5b58&to=aeae054055b125b011c1122f82c86457e159436f&stat=instructions

Reviewed By: djtodoro

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

Fixes #49188.

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

Reviewed as part of D119184.

If the shift amount has been zero-extended, peek through as this might help us further canonicalize the shift amount.

Fixes regression mentioned in rG147cfcbef1255ba2b4875b76708dab1a685085f5

Pass LIBCXX_HAS_PTHREAD_LIB, LIBCXX_HAS_RT_LIB  and LIBCXXABI_HAS_PTHREAD_LIB
through to the custom lib++ builds so that libfuzzer  doesn't end up with a .deplibs section that
links against those libraries when the variables are set to false.

Reviewed By: phosek

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

With modern architectures having a thread pointer and language supporting
thread locals, there is no reason to use a function intermediary to access
the thread local errno value.

The entrypoint corresponding to errno has been replaced with an object
library as there is no formal entrypoint for errno anymore.

Reviewed By: jeffbailey, michaelrj

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

Adds `MatchSwitch`, a library for simplifying implementation of transfer
functions. `MatchSwitch` supports constructing a "switch" statement, where each
case of the switch is defined by an AST matcher. The cases are considered in
order, like pattern matching in functional languages.

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

Reviewed By: bondhugula

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

This patch adds a simpe lattice used to collect source loctions. An intended application is to track errors found in code during an analysis.

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

This patch extends the existing if combining canonicalization to also handle the case where a value returned by the first if is used within the body of the second if.

This patch also extends if combining to support if's whose conditions are logical negations of each other.

Reviewed By: ftynse

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

When lowering LLVM-IR to instruction referencing stuff, if a value is
defined by a COPY, we try and follow the register definitions back to where
the value was defined, and build an instruction reference to that
instruction. In a few scenarios (such as arguments), this isn't possible.
I added some assertions to catch cases that weren't explicitly whitelisted.

Over the course of a few months, several more scenarios have cropped up,
the lastest is the llvm.read_register intrinsic, which lets LLVM-IR read an
arbitary register at any point. In the face of this, there's little point
in validating whether debug-info reads a register in an expected scenario.
Thus: this patch just deletes those assertions, and adds a regression test
to check that something is done with the llvm.read_register intrinsic.

Fixes #54190

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

Reviewed By: ftynse

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

[X86] LowerShiftByScalarVariable - find splat patterns with getSplatSourceVector instead of getSplatValue

This completes the removal of uses of SelectionDAG::getSplatValue started in D119090 - by avoiding extracting the splatted element we make it a lot easier to zero-extend the bottom 64-bits of the shift amount and fixes issues we had on 32-bit targets where i64 isn't legal.

I've removed the old version of getTargetVShiftNode that took the scalar shift amount argument and LowerRotate can finally efficiently handle vXi16 rotates-by-scalar (using the same code as general funnel-shifts).

The only regression we see is in the X86-AVX2 PR52719 test case in vector-shift-ashr-256.ll - this is now hitting the same problem as the X86-AVX1 case (failure to simplify a multi-use X86ISD::VBROADCAST_LOAD) which I intend to address in a follow up patch.

It caused builds to assert with:

  (StackSize == 0 && "We already have the CFA offset!"),
  function generateCompactUnwindEncoding, file AArch64AsmBackend.cpp, line 624.

when targeting iOS. See comment on the code review for reproducer.

> This patch rearranges emission of CFI instructions, so the resulting
> DWARF and `.eh_frame` information is precise at every instruction.
>
> The current state is that the unwind info is emitted only after the
> function prologue. This is fine for synchronous (e.g. C++) exceptions,
> but the information is generally incorrect when the program counter is
> at an instruction in the prologue or the epilogue, for example:
>
> ```
> stp     x29, x30, [sp, #-16]!           // 16-byte Folded Spill
> mov     x29, sp
> .cfi_def_cfa w29, 16
> ...
> ```
>
> after the `stp` is executed the (initial) rule for the CFA still says
> the CFA is in the `sp`, even though it's already offset by 16 bytes
>
> A correct unwind info could look like:
> ```
> stp     x29, x30, [sp, #-16]!           // 16-byte Folded Spill
> .cfi_def_cfa_offset 16
> mov     x29, sp
> .cfi_def_cfa w29, 16
> ...
> ```
>
> Having this information precise up to an instruction is useful for
> sampling profilers that would like to get a stack backtrace. The end
> goal (towards this patch is just a step) is to have fully working
> `-fasynchronous-unwind-tables`.
>
> Reviewed By: danielkiss, MaskRay
>
> Differential Revision: https://reviews.llvm.org/D111411

This reverts commit 32e8b550.

mov w8, #1325400064 + fmov s0, w8 ==> movi v0.2s, 0x4f, lsl 24
Fix https://github.com/llvm/llvm-project/issues/53651

Reviewed By: dmgreen, fhahn

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

Remove the executable name from the test match as this will have
a `.exe` suffix on windows.

Reviewed By: drodriguez

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