Since the new data operand operations have been added in D148389 and
adopted on acc.update in D149909, the old clause operands are no longer
needed. This is a first patch to start cleaning the OpenACC operations
with data clause operands.

The `LegalizeDataOpForLLVMTranslation` will become obsolete when all
operations will be cleaned. For the time being only the appropriate
part are being removed.

`processOperands` will also receive some updates once all the operands
will be coming from an acc data operand operation.

Reviewed By: razvanlupusoru, jeanPerier

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

The previous include guard (_REGEX_H_) is also used in a macOS SDK
header (xlocale.h), causing potential for trouble. This was previously
addressed in 2b8b90a7, but renaming the
macro in line with LLVM's other include guards seems like a better fix.

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

This helps avoid constant materialization for the patterns
InstCombine emits for something like INT_MIN <= X && x <= INT_MAX.

See top of changed test files for more detailed explanation.

I've enabled this for i16 when Zbb is enabled. sext.b did not seem
to be a benefit due to the constants folding into addi/sltiu.

This an alternative to https://reviews.llvm.org/D149814

Reviewed By: reames

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

This previously returned a bool to indicate success or failure and
returns a register through an output parameter.

Some callers used the bool to check for success. Some callers checked
for RISCV::NoRegister.

To make everything uniform, return the MCRegister directly and update
all callers to use MCRegister::isValid().

Reviewed By: barannikov88

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

Fix a mutation of `CommandAlias::m_option_args_sp`, which resulted in cases where
aliases would fail to run on second, and subsequent times.

For example, an alias such as:

```
command alias p1 p 1
```

When run the second time, the following error would be reported to the user:

```
error: expression failed to parse:
error: <user expression 1>:1:1: expression is not assignable
--  1
^   ~
```

To fix this, `CommandAlias::Desugar` now constructs options to a freshly constructed
vector, rather than by appending to the results of `GetOptionArguments`.

rdar://107770836

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

The logic of whether an entity needs to be captured has become
quite complex and the recent changes in https://reviews.llvm.org/D124351
ad a mesurable negative impact on compile times.

However, in the absence of capturing scopes (lambda, block, region)
we usually can avoid running most of that logic
(except that we do need to diagnostic when a nested function
refers to a local variable in the scope of the outer function.).

This patch track whether there is currently an active capturing
scope and exit `tryCaptureVariable` early when there isn't.

Reviewed By: aaron.ballman

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

Reviewed By: jhuber6

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

Data operands associated with acc.parallel, acc.serial and
acc.kernels should comes from acc data entry/exit operations
or acc.getdeviceptr.

Reviewed By: razvanlupusoru, jeanPerier

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

Data operands associated with acc.update should comes
from acc data entry/exit operations or acc.getdeviceptr.

Reviewed By: razvanlupusoru

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

This patch introduces a VPRecipeWithIRFlags class to record various IR
flags for a recipe. This allows de-coupling of IR flags from the
underlying instructions. The main benefit is that it allows dropping of
IR flags from recipes directly, without the need to go through
State::MayGeneratePoisonRecipes. The plan is to remove
MayGeneratePoisonRecipes once all relevant recipes are transitioned.

It also allows dropping IR flags during VPlan-to-VPlan transforms, which
will be used in a follow-up patch to implement truncateToMinimalBitwidths
as VPlan-to-VPlan transform.

Reviewed By: Ayal

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

Data operands associated with acc.enter_data should comes
from acc data entry operations.

Reviewed By: razvanlupusoru

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

Data operands associated with acc.data should comes
from acc data entry/exit operations or acc.getdeviceptr.

Reviewed By: razvanlupusoru

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

Currently the opcode is only valid if it is the same between all of the
ports. This is possible to violate if the opcode is places into a memory
location and then read in a non-uniform manner by the warp / wavefront.
Moving this to a compile time constant makes it impossible to break this
invariant.

Reviewed By: JonChesterfield

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

This syntax is confusing and likely invalid. In addition, MASM rejects
it and GAS seems to behave oddly with it. Therefore we shall reject this
syntax for both unconditional `call` and `jmp` instructions, as
discussed in D149579.

Depends on D150047

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

In the past, D71436 added writing the `offset` operator for some
legitimate cases. However, for memory references in Intel syntax, the
`offset` operator (`[offset sym]`) appears to be superfluous at best,
possibly wrong and contradictory at worst.

This patch bypasses writing the `offset` operator in
`X86AsmPrinter::PrintIntelMemReference` which affects exactly this
case. A similar code flow exists in `X86IntelInstPrinter.cpp` -
`X86IntelInstPrinter::printMemReference`.

The motivation for fixing this output is to allow us to reject the
confusing `call [offset fn_ref]` syntax in MC, as discussed in D149579.

Depends on D149579

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

Clang on Windows targets often requires indirect calls through the
import address table (IAT), and also .refptr stubs for MinGW target.
On 32-bit this generates assembly in the form of
`call dword ptr [__imp__func]`, which MC had failed to handle correctly.
64-bit targets are not affected because rip-relative addressing is used.

Reported on: https://github.com/llvm/llvm-project/issues/62010

Depends on D149695, D149920

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

Useful for easier debugging (no need to regex out all of the stuff around the id).

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

This is part of an on-going migration to adopt Properties inside MLIR.

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

This is part of an on-going migration to adopt Properties inside MLIR.

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

This is part of an on-going migration to adopt Properties inside MLIR.

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

This is part of an on-going migration to adopt Properties inside MLIR.

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

This is part of an on-going migration to adopt Properties inside MLIR.

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

This is part of an on-going migration to adopt Properties inside MLIR.

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

With cb57b7a7, the kill flags are now tracked during the forward search over
the instructions and the call to findRegisterUseOperandIdx() should therefore
only check for killing uses.

As shown with the failing test CodeGen/Hexagon/vector-sint-to-fp.ll, it could
otherwise be the case that an undef use after the instruction that killed the
register will be inserted into MBBKills, and the kill flag will not be
cleared.

Adds an LTO option to indicate that whether we are linking with an
allocator that supports hot/cold operator new interfaces. If not,
at the start of the LTO backends any existing memprof hot/cold
attributes are removed from the IR, and we also remove memprof metadata
so that post-LTO inlining doesn't add any new attributes.

This is done via setting a new flag in the module summary index. It is
important to communicate via the index to the LTO backends so that
distributed ThinLTO handles this correctly, as they are invoked by
separate clang processes and the combined index is how we communicate
information from the LTO link. Specifically, for distributed ThinLTO the
LTO related processes look like:
```
   # Thin link:
   $ lld --thinlto-index-only obj1.o ... objN.o -llib ...
   # ThinLTO backends:
   $ clang -x ir obj1.o -fthinlto-index=obj1.o.thinlto.bc -c -O2
   ...
   $ clang -x ir objN.o -fthinlto-index=objN.o.thinlto.bc -c -O2
```

It is during the thin link (lld --thinlto-index-only) that we have
visibility into linker dependences and want to be able to pass the new
option via -Wl,-supports-hot-cold-new. This will be recorded in the
summary indexes created for the distributed backend processes
(*.thinlto.bc) and queried from there, so that we don't need to know
during those individual clang backends what allocation library was
linked. Since in-process ThinLTO and regular LTO also use a combined
index, for consistency we query the flag out of the index in all LTO
backends.

Additionally, when the LTO option is disabled, exit early from the
MemProfContextDisambiguation handling performed during LTO, as this is
unnecessary.

Depends on D149117 and D149192.

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

This test was originally unsupported for `LIBCXX-AIX-FIXME` feature because we lacked `-fvisibility=hidden` support. AIX now has visibility support and the test passes in debug mode.

Reviewed By: #libc, Mordante

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

When running bcc tool execsnoop ([1]) which is built with latest llvm,
I hit the following error:
  $ sudo ./execsnoop.py
  /virtual/main.c:99:157: error: expected ')'
    data.ppid = ({ typeof(pid_t) _val; __builtin_memset(&_val, 0, sizeof(_val)); bpf_probe_read(&_val, sizeof(_val),
       (void *)&({ typeof(struct task_struct  btf_type_tag(rcu)*) _val; __builtin_memset(&_val, 0, sizeof(_val));
                                              ^
        bpf_probe_read(&_val, sizeof(_val), (void *)&task->real_parent); _val; })->tgid); _val; });

The failure reason is due to that the bcc rewriter printed type like
  struct task_struct  btf_type_tag(rcu)*
where the compiler cannot recognize what 'btf_type_tag(rcu)' is.

The above type is printed in [2] by UnaryOperator->getType().getAsString() (from clang)
in function ProbeVisitor::VisitUnaryOperator.

The original source type looks like ([3])
  struct task_struct {
    ...
    struct task_struct __rcu	*real_parent;
    ...
  }
  where '__rcu' is a macro expanding to '__attribute__((btf_type_tag("rcu")))'.

Let us print btf_type_tag properly in clang so bcc tools and broader type printing
will work properly.

With this patch, the above rewrited source code looks like
    data.ppid = ({ typeof(pid_t) _val; __builtin_memset(&_val, 0, sizeof(_val)); bpf_probe_read(&_val, sizeof(_val),
       (void *)&({ typeof(struct task_struct  __attribute__((btf_type_tag("rcu")))*) _val; __builtin_memset(&_val, 0, sizeof(_val));
        bpf_probe_read(&_val, sizeof(_val), (void *)&task->real_parent); _val; })->tgid); _val; });

and execsnoop.py tool can run properly.

  [1] https://github.com/iovisor/bcc/blob/master/tools/exitsnoop.py
  [2] https://github.com/iovisor/bcc/blob/master/src/cc/frontends/clang/b_frontend_action.cc
  [3] https://github.com/torvalds/linux/blob/master/include/linux/sched.h

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

Share with AVX512 to reduce duplication

Fixes #62462

Reviewed By: #clang-language-wg, erichkeane

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

In the SimplifyDemandedBits function, there is a fallthrough to the
default case in the case of ISD::ADD, ISD::MUL and ISD::SUB. This
leads to a call to computeKnownBits which is unnecessary as the
calls to SimplifyDemandedBits in the cases themselves handle the
calculation of the known bits. This information is discarded through
the Known2 variables.

By keeping this information around and calling
KnownBits::mul or KnownBits::computeForAddSub directly, the
unnecessary computation can be avoided. For now, the NSW bit is not
passed through to KnownBits as this is something that
computeKnownBits does not handle either. This requires updating
computeForAddCarry to handle the flag as well.

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

Implements part of P1614R2 "The Mothership has Landed"

Reviewed By: Mordante, #libc, philnik

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

These were recently deprecated in https://reviews.llvm.org/D149464.

Reviewed By: ymandel, gribozavr2, xazax.hun

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

Don't choke on `outs` arguments that are not produced by `tensor.empty` or
`tensor.extract_slice`.

When the `outs` argument has a static shape we have all the necessary
information to proceed with the padding.

This makes the `transform.structured.pad` a little bit more resilient.

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

The commit causes build bot failures due to a missing dependencies:
https://buildkite.com/llvm-project/llvm-main/builds/7036#0187fb40-e4b6-4471-a2a0-2820b71c727b

This reverts commit 91cff8a7.

This change fixes static code analysis errors

Reviewed By: skan

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

Currently `CallOpInterface` has a method `getCallableForCallee` to have a consistent way to get the callee from an operation with `CallOpInterface`, but missing a consistent way to set a callee for an operation with `CallOpInterface`.

A set callee method is useful for transformations that operate on `CallOpInterface`, and change the callee, e.g., a pass that specialize function, which clone the callee, and change the `CallOpInterface`'s callee to the cloned version. Without such method, transformation would need to understand the implementation for every operations with `CallOpInterface`, and have a type switch to handle them.

This review adds a method to set callee for operation with `CallOpInterface`.

Reviewed By: gysit, zero9178o

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

This patch refactors the Mem2Reg infrastructure. It decouples
analysis from promotion, allowing for more control over the execution of
the logic. It also adjusts the interfaces to be less coupled to mem2reg
and more general. This will be useful for an upcoming revision
introducing generic SROA.

Reviewed By: gysit

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