Includes verifier changes checking the elementtype, clang codegen
changes to emit the elementtype, and ISel changes using the elementtype.

Reviewed By: #opaque-pointers, nikic

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

This patch lowers common block variable to FIR.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: PeteSteinfeld

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



Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>

Use of setarch Was added by
https://github.com/llvm/llvm-project/commit/f93c2b64ed381bc4bc52f4b8539026f1597f574d

Running the test now it doesn't seem necessary because:

1) Explicitly only x86_64 is supported for dfsan.

2) https://reviews.llvm.org/D111522 makes it less flakey.

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

[IROutliner] Avoid reusing PHINodes that have already been matched when merging outlined functions' phi node blocks

When there are two external phi nodes for two different outlined regions, when compressing the created phi nodes between the two regions, the matching for the second phi node in the second region matches the first phi node created for the first region rather than the second phi node created for the first region. This adds an extra output path where there should not be one.

The fix is the ignore phi nodes that have already been matched for each region.

Reviewer: paquette

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

Lower the `all` intrinsic procedure.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: PeteSteinfeld

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



Co-authored-by: mleair <leairmark@gmail.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>

This fixes the implicit module build after b1b4b6f3 broke the LLDB
build: https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/42084/

My previous commit didn't have the modulemap change staged.

RequireAnalysis<GlobalsAA> doesn't actually recompute GlobalsAA.
GlobalsAA isn't invalidated (unless specifically invalidated) because
it's self-updating via ValueHandles, but can be imprecise during the
self-updates.

Rather than invalidating GlobalsAA, which would invalidate AAManager and
any analyses that use AAManager, create a new pass that recomputes
GlobalsAA.

Fixes #53131.

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

This patch adds more lowering of operations sub-expression inside elemental call arguments.
It tests array contexts where an address is needed for each element (for
the argument), but part of the array sub-expression must be lowered by value
(for the operation)

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: PeteSteinfeld

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



Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

We still need the code after stripAndAccumulateConstantOffsets() since
it doesn't handle GEPs of scalable types and non-constant but identical
indexes.

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

Bug introduced in fbbc41f8

The test was marked as XFAIL on Windows, but recent changes have made it flaky instead

This fixes the implicit module build after b1b4b6f3 broke the LLDB
build: https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/42084/

Move ProgressEventData out of debugger and into its own file. This is in
preparation of adding a few new type of event data for diagnostics.

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

DSE assumes that this is the case when forming a calloc from a
malloc + memset pair.

For tests, either update the malloc signature or change the
data layout.

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

Followup/fix for https://reviews.llvm.org/D121349.

This changes the clang-tidy script to discover binaries you've built
locally without having to pass them.

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

This change continues to lay the ground work for supporting extended
const expressions in the linker.

The included test covers object file reading and writing and the YAML
representation.

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

In this case we may not generate a bitcast, so the new load/store
becomes the external user.

command-thread-siginfo.test employs a subject with a call to wait, and
thus requires system-linux. However, it's possible to target non-Linux
platforms despite operating on Linux hosts. So, have it require native
too.

Reviewed By: mgorny, labath

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

The argument is not used, remove it.

The `opt -analyze` option only works with the legacy pass manager and might be removed in the future, as explained in llvm.org/PR53733. This patch introduced -polly-print-* passes that print what the pass would print with the `-analyze` option and replaces all uses of `-analyze` in the regression tests.

There are two exceptions: `CodeGen\single_loop_param_less_equal.ll` and `CodeGen\loop_with_condition_nested.ll` use `-analyze on the `-loops` pass which is not part of Polly.

Reviewed By: aeubanks

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

Implement the vectorLoopUnroll interface for MultiDimReduceOp and add a
pattern to do the unrolling following the same interface other vector
unroll patterns.

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

According to LangRef, an access scope must have zero operands and
be distinct. The access group may either be a single access scope
or a list of access scopes.

LoopInfo may assert if this is not the case.

VSX introduced some permute instructions that are direct
replacements for Altivec ones except they can target all
the VSX registers. We have added code generation for most
of these but somehow missed the low/hi word merges (XXMRG[LH]W).
This caused some additional spills on some large
computationally intensive code.

This patch simply adds the missed patterns.

This reverts commit a140b710.

It provoked the bug https://github.com/llvm/llvm-project/issues/54374.

llvm.fma|fmuladd vp.fma isel and tests

Reviewed By: kaz7

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

Previously, the test checked for a "undefined symbol" error
(instead of the "could not open std*.lib" which would happen without
the flag).

Instead, use /entry: so that the link succeeds.

No behavior change, but maybe makes the test a bit easier to understand.

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

For landingpads with {} type, SCCP ended up dropping them, because
we considered them as safe to remove.

Implement exp2f function that is correctly rounded for all rounding modes.

Reviewed By: sivachandra, zimmermann6

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

WG14 adopted N2775 (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2775.pdf)
at our Feb 2022 meeting. This paper adds a literal suffix for
bit-precise types that automatically sizes the bit-precise type to be
the smallest possible legal _BitInt type that can represent the literal
value. The suffix chosen is wb (for a signed bit-precise type) which
can be combined with the u suffix (for an unsigned bit-precise type).

The preprocessor continues to operate as-if all integer types were
intmax_t/uintmax_t, including bit-precise integer types. It is a
constraint violation if the bit-precise literal is too large to fit
within that type in the context of the preprocessor (when still using
a pp-number preprocessing token), but it is not a constraint violation
in other circumstances. This allows you to make bit-precise integer
literals that are wider than what the preprocessor currently supports
in order to initialize variables, etc.

Due to various implementation constraints, despite the programmer
choosing a 'processor' cpu_dispatch/cpu_specific needs to use the
'feature' list of a processor to identify it. This results in the
identified processor in source-code not being propogated to the
optimizer, and thus, not able to be tuned for.

This patch changes to use the actual cpu as written for tune-cpu so that
opt can make decisions based on the cpu-as-spelled, which should better
match the behavior expected by the programmer.

Note that the 'valid' list of processors for x86 is in
llvm/include/llvm/Support/X86TargetParser.def. At the moment, this list
contains only Intel processors, but other vendors may wish to add their
own entries as 'alias'es (or with different feature lists!).

If this is not done, there is two potential performance issues with the
patch, but I believe them to be worth it in light of the improvements to
behavior and performance.

1- In the event that the user spelled "ProcessorB", but we only have the
features available to test for "ProcessorA" (where A is B minus
features),
AND there is an optimization opportunity for "B" that negatively affects
"A", the optimizer will likely choose to do so.

2- In the event that the user spelled VendorI's processor, and the
feature
list allows it to run on VendorA's processor of similar features, AND
there
is an optimization opportunity for VendorIs that negatively affects
"A"s,
the optimizer will likely choose to do so. This can be fixed by adding
an
alias to X86TargetParser.def.

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

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

The argument is not used, remove it.

With opaque pointers, the bitcast might be a no-op, and this can
end up trying to replace a value with itself, which is illegal.

This change teaches the Sema logic for `__builtin_memcpy_inline` to implicitly convert arrays passed as arguments to pointers, similarly to regular `memcpy`.

This code will no longer cause a compiler crash:
```
void f(char *p) {
    char s[1] = {0};
    __builtin_memcpy_inline(p, s, 1);
}
```

rdar://88147527

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