When cross-compiling NVPTX we use the triple to indicate which paths to
search for the CUDA toolchain. Currently this uses the default target
triple. This might not be exactly correct, as this is the default triple
used to compile binaries, not the host system. We want the host triple
because it indicates which folders should hold CUDA.

Reviewed By: tra

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

This uses the same sequence we get from LegalizeDAG for i32 on RV32, but modified
to use W instructions.

When the RHS is constant one of the setccs simplifies to a constant and the xor will either
be an xori with 1 or get removed.

When the RHS is not a constant it was not an obvious improvement and it was a regression
when used with a branch. So I've restricted to the constant case.

Reviewed By: reames

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

No longer lie about them only being 30 minutes long and add Fridays.

Reviewed By: aaron.ballman

Spies: cfe-commits

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

Reviewed By: michaelrj

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

Fix windows bot failure from b8d2f717:

https://lab.llvm.org/buildbot/#/builders/216/builds/20923

by switching uint to unsigned, as the former is not recognized there.

This patch adds the additional step of looking through AND, OR, XOR
instructions when we check the number of leading zeros.

Reviewed By: shchenz

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

Breaks PPC bots, see D143467.

This reverts commit 651b0e2e.

Currently when using designated initializers in C++ we have a few
extension. Two extension which are dangerous involved assigning to
multiple members of union which will likely be a mistake since unions
can only have one active member. I have updated to be a warning by
default.

The second case if when we assign to multiple union members and one of
the previous members had a non-trivial destructor, which could lead to
leaking resources. This one is now an error by default.

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

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

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

isDeductionGuideName looks up the underlying template and if the template name
is qualified we miss that qualification resulting in an error. This issue
resurfaced in clang-repl where we call isDeductionGuideName more often to
distinguish between if we had a statement or declaration.

This patch passes the CXXScopeSpec information down to LookupTemplateName to
make the lookup more precise.

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

The existing vector.transpose lowering patterns only triggers if the
input vector is 2D. The revision extends the pattern to handle n-D
vectors which are effectively 2-D vectors (e.g., vector<1x4x1x8x1).

It refactors a common check about 2-D vectors from X86Vector
lowering to VectorUtils.h so it can be reused by both sides.

Reviewed By: dcaballe

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

escaped_output.unicode.pass.cpp is failing only on 32-bit AIX. The rest are passing.

Reviewed by: #libc, Mordante

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

Add "Hot" AllocationType (in addition to existing cold, notcold).

Use lifetime access density as metric to identify hot allocations.
Treat hot as notcold for MemProfContextDisambiguation for now
before the disambiguation for "hot" is done.

Reviewed By: tejohnson

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

We have four places that we try to decide which name to use for the
test for structural equivalence, and in each of those we evaluate
getTypedefNameForAnonDecl twice. Pull out the check into a function to
reduce duplication and evaluate things only once.

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

Fix the last runtime issue as some sequent comparisons need be spilted.
For the origin equal comparisons chain, the new spilted Icmp chain will
still be end with equal, while for the new not-equal comparisons chain,
the new spilted Icmp chain will still be end with equal, so should address
this carefully, see detail wih case partial_sequent_ne

Thanks for @aeubanks, @glandium and @ayzhao report the runtime issue
and carefully examine.
Fix https://github.com/llvm/llvm-project/issues/59740.

Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D141188

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