Create 2 users for MOVMSK to test if compiler would perform the combine
"MOVMSK(CONCAT(X,Y)) == 0 ->  MOVMSK(OR(X,Y))".

The current implementation of takeBody first clears the Region, before then taking ownership of the blocks of the other regions. The issue here however, is that when clearing the region, it does not take into account references of operations to each other. In particular, blocks are deleted from front to back, and operations within a block are very likely to be deleted despite still having uses, causing an assertion to trigger [0].

This patch fixes that issue by simply calling dropAllReferences()before clearing the blocks.

[0] https://github.com/llvm/llvm-project/blob/9a8bb4bc635de9d56706262083c15eb1e0cf3e87/mlir/lib/IR/Operation.cpp#L154

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

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

Reviewed By: aaron.ballman

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

Default nameTableKind results in the following DWARF section:

    .section .debug_pubnames
    {
      .b32 LpubNames_end0-LpubNames_start0    // Length of Public Names Info
      LpubNames_start0:
      [...]
      LpubNames_end0:
    }

Without -mattr=+ptx75 ptxas complains about labels and label
expressions:

error   : Feature 'labels1 - labels2 expression in .section' requires
PTX ISA .version 7.5 or later
error   : Feature 'Defining labels in .section' requires PTX ISA
.version 7.0 or later

The patch modifies dbg-value-const-byref.ll to let it run without PTX
7.5 (available from CUDA 11.0), and adds a new test just for this
case.

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

This reverts commit 360d44e8.

This makes the code a bit simpler and (I think) removes the undefined behaviour from the normal string layout.

Reviewed By: ldionne, Mordante, #libc

Spies: labath, dblaikie, JDevlieghere, krytarowski, jgorbe, jingham, saugustine, arichardson, libcxx-commits

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

The code needs more TLC, but for now I've tried making only the changes
that are necessary to get the tests passing -- postponing the more
invasive changes after I create a more comprehensive test.

In a couple of places I have changed the index-based element accesses to
name-based ones (as these are less sensitive to code perturbations). I'm
not sure why the code was using indexes in the first place, but I've
(manually) tested the change with various libc++ versions, and found no
issues with this approach.

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

Debugify in OriginalDebugInfo mode, does (DebugInfo) collect-before-pass & check-after-pass
for each instruction, which is pretty expensive. When used to analyze DebugInfo losses
in large projects (like LLVM), this raises the build time unacceptably.
This patch introduces a limit for the number of processed functions per compile unit.
By default, the limit is set to UINT_MAX (practically unlimited), and by using the introduced
option  -debugify-func-limit  the limit could be set to any positive integer number.

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

Prior to this patch, `cloneInto` would do a simple walk over the blocks and contained operations and clone and map them as it encounters them. As finishing touch it then remaps any successor and operands it has remapped during that process.

This is generally fine, but sadly leads to a lot of uses of both operations and blocks from the source region, in the cloned operations in the target region. Those uses lead to writes in the use-def list of the operations, making `cloneInto` never thread safe.

This patch reimplements `cloneInto` in three steps to avoid ever creating any extra uses on elements in the source region:
* It first creates the mapping of all blocks and block operands
* It then clones all operations to create the mapping of all operation results, but does not yet clone any regions or set the operands
* After all operation results have been mapped, it now sets the operations operands and clones their regions.

That way it is now possible...

- added views::join adaptor object
- added test for the adaptor object
- fixed some join_view's tests. e.g iter_swap test
- added some negative tests for join_view to test that operations do not exist when constraints aren't met
- added tests that locks down issues that were already addressed in previous change
  - LWG3500 `join_view::iterator::operator->()` is bogus
  - LWG3313 `join_view::iterator::operator--` is incorrectly constrained
  - LWG3517 `join_view::iterator`'s `iter_swap` is underconstrained
  - P2328R1 join_view should join all views of ranges
- fixed some issues in join_view and added tests
  - LWG3535 `join_view::iterator::iterator_category` and `::iterator_concept` lie
  - LWG3474 Nesting ``join_views`` is broken because of CTAD
- added tests for an LWG issue that isn't resolved in the standard yet, but the previous code has workaround.
  - LWG3569 Inner iterator not default_initializable

Reviewed By: #libc, var-const

Spies: var-const, libcxx-commits

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

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

Add async dependencies support for gpu.launch op: this allows specifying
a list of async tokens ("streams") as dependencies for the launch.

Update the GPU kernel outlining pass lowering to propagate async
dependencies from gpu.launch to gpu.launch_func op. Previously, a new
stream was being created and destroyed for a kernel launch. The async
deps support allows the kernel launch to be serialized on an existing
stream.

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

Reviewed By: yota9, rafauler

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

The gcc 7.3.0 version raises "could not covert" error without std::move
used explicitly.

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

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

The following code causes the compiler to ICE in several places due to
lack of support of recursive procedure definitions through the function
result.

  function foo() result(r)
    procedure(foo), pointer :: r
  end function foo

An empty commit to test the access

Ensure that any `read_write` image type carries the
`__opencl_c_read_write_images` upon construction of the `ImageType`.

to consistent with other tweaks.

Rather than creating a PHI node and then using the PHI threading
code, directly handle this case in
FoldCondBranchOnValueKnownInPredecessor().

This change is supposed to be NFC-ish, but may cause changes due
to different transform order.

This is a followup of https://reviews.llvm.org/D123127, adding support
for the QualifiedTemplateName.

Reviewed By: sammccall

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

This general threading transform can be performed whenever we know
a constant value for the condition in a predecessor, which would
currently just be the case of a phi node with constant arguments.

The related instructions are:

VPERMD/Q/PS/PD
VRANGEPD/PS/SD/SS
VGETMANTSS/SD/SH
VGETMANDPS/PD - mem version only
VPMULLQ
VFMULCSH/PH
VFCMULCSH/PH

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

This reverts commit 3b132300.

It looks like GVNSink is currently non-deterministic, due to an
std::sort() on BasicBlock* pointers in ModelledPHI. This becomes
visible in the generated checks.

This reverts commit 0d406889.

We saw a failure caused by unwinding with incomplete CFIs, so we
can't outline CFI instructions when they are needed in EH.

Reviewed By: luismarques

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

Reviewed By: luismarques

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

Add a new CMake file to expand on for more problematic configurations
in the future.

Related to #54645

Reviewed By: beanz, phosek, smeenai

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

This patch adds lowering support for atomic read and write constructs.
Also added is pointer modelling code to allow FIR pointer like types to
be inferred and converted while lowering.

Reviewed By: kiranchandramohan

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



Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>

Shader attribute is for shader library identify entry functions.
Here's an example,

[shader("pixel")]
float ps_main() : SV_Target {
  return 1;
}

When compile this shader to library target like -E lib_6_3, compiler needs to know ps_main is an entry function for pixel shader. Shader attribute is to offer the information.

A new attribute HLSLShader is added to support shader attribute. It has an EnumArgument which included all possible shader stages.

Reviewed By: aaron.ballman, MaskRay

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

We can't shift-right negative numbers to divide them, so avoid emitting
such sequences. Use negative numerators as a proxy for this situation, since
the indices are always non-negative.

An alternative strategy could be to add a compiler flag to emit division
instructions, which would at least allow us to test the VID sequence
matching itself.

Reviewed By: craig.topper

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

This test shows a (contrived) BUILD_VECTOR which is correctly identified
as a sequence of ((vid * -3) / 8) + 5. However, the issue is that using
shift-right for the divide is invalid as the step values are negative.

This patch just adds the test: the fix is added in D123796.

Reviewed By: craig.topper

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

Linux kernel arch/arm64/kernel/vmlinux.lds.S discards .dynsym . D123985 triggers
a spurious assertion failure. Detect the case with
`!mainPart->dynSymTab->getParent()`.