The moved `populate` methods are only relevant to Linalg
operations. So they are better of in `linalg` namespace.  Also rename
`populateLinalgTensorOpsFusionPatterns` to
`populateElementwiseOpsFusionPatterns`. This makes the scope of these
patterns explicit and disambiguates it with fusion on tensors using
tile + fuse.

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

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

This reverts commit 43ceb74e.

This caused some build failures: https://bugs.llvm.org/show_bug.cgi?id=49818

This reverts commit d66f9c4f.

This was a follow up fix for 43ceb74e, which
will be reverted.

TextAPI/ELF has moved out into InterfaceStubs, so theres no longer a
need to seperate out TextAPI between formats.

Reviewed By: ributzka, int3, #lld-macho

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

This patch adds two debug functions to ExprInspectionChecker to dump out
the dynamic extent and element count of symbolic values:
dumpExtent(), dumpElementCount().

[flang][driver] Modify the existing test cases that use -Mstandard in f18, to use -pedantic and %flang_fc1 to share with the new driver

Reviewed By: awarzynski

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

If only the second candidate loop is guarded while the first one is not, fusioning
two loops might not be valid but this check is currently missing.

Fixes https://bugs.llvm.org/show_bug.cgi?id=48060

Reviewed By: sidbav

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

This patch introduces a way to store the size.

Reviewed By: NoQ

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

With the option given, warnings are treated as error.

Reviewed By: awarzynski

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

This patch supports bitcasts from scalar types to fixed-length vectors
and vice versa. It custom-lowers and custom-legalizes them to
EXTRACT_VECTOR_ELT/INSERT_VECTOR_ELT operations, using a single-element
vectors to hold the scalar where appropriate.

Previously, some of these would fail to select, others would be expanded
through stack loads and stores. Effort was made to ensure the codegen
avoids the stack for both legal and illegal scalar types.

Some of the codegen could be improved, but on first glance it looks like
a general optimization of EXTRACT_VECTOR_ELT when extracting an i64
element on RV32.

Reviewed By: craig.topper

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

As shown in the example based on:
https://llvm.org/PR49832
...and the existing test, we can't substitute
a vector value because the equality compare
replacement that we are attempting requires
that the comparison is true for the entire
value. Vector select can be partly true/false.

The new test is reduced from:
https://llvm.org/PR49832
...but we already show a potential miscompile in the existing test too.

In 0dbcb363, most most target symbols were made hidden by default
with the public ones marked with LLVM_EXTERNAL_VISIBILITY. When the
M68k target was added, this particular change was forgotten so that
external tools cannot make use of the public M68k target functions
in libLLVM.so. Thus, add the missing LLVM_EXTERNAL_VISIBILITY macro
to all public target functions in the M68k backend.

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

Caught in internal testing, these operations are assumed legal by
default, even for scalable vector types. Expand them back into separate
truncations and stores, or loads and extensions.

Also add explicit fixed-length vector tests for these operations, even
though they should have been correct already.

Reviewed By: craig.topper

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

Clang used to emit a bad -Wbridge-cast diagnostic on the cast in the attached
test. This was because, after 09abecef, struct __CFString was not added to
lookup, so the objc_bridge attribute wasn't getting duplicated onto the most
recent declaration, causing us to fail to find it in getObjCBridgeAttr. This
patch fixes this by instead walking through the redeclarations to find an
appropriate bridge attribute. rdar://72823399

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

From the PowerPC ELFv2 ABI section 4.2.3. Global Offset Table.
```
The GOT consists of an 8-byte header that contains the TOC base (the first TOC
base when multiple TOCs are present), followed by an array of 8-byte addresses.
```

Due to the introduction of PC Relative code it is now possible to require a GOT
without having a .TOC. symbol in the object that is being linked. Since LLD uses
the .TOC. symbol to determine whether or not a GOT is required the GOT header is
not setup correctly and the 8-byte header is missing.

This patch allows the Power PC GOT setup to happen when an element is added to
the GOT instead of at the very begining. When this header is added a .TOC.
symbol is also added.

Reviewed By: MaskRay

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

The second argument to the strnlen_s(str, size) function should be
sizeof(str) when str is a true array of characters with known size
(instead of just a char*). Use type traits to determine if first
parameter is a character array and use the correct size based on that
trait.

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

During vectorization better to postpone the vectorization of the CmpInst
instructions till the end of the basic block. Otherwise we may vectorize
it too early and may miss some vectorization patterns, like reductions.

Reworked part of D57059

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

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

This patch introduces a DIPrinter interface to implement by different output style printer implementations. DIPrinterGNU and DIPrinterLLVM implement the GNU and LLVM output style printing respectively. No functional changes.

This refactoring clarifies and simplifies the code, and makes a new output style addition easier.

Reviewed By: jhenderson, dblaikie

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

This patch adds a test which shows how the compiler incorrectly sets the
size and alignment of a stack object used to indirectly pass vector
types to functions.

In the particular example, the test passes a <4 x i8> vector type to a
function and creates a stack object of size and alignment equal to 4
bytes. However, the code generated to set up that parameter has been
scalarized and stores each element as individual XLEN-sized values. Thus
on RV32 this stores 16 bytes and on RV64 32 bytes, both of which clobber
the stack. Similarly, the alignment is set up as the alignment
of the vector type, which is not necessarily the natural alignment of XLEN.

Reviewed By: luismarques

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

Fixes PR47603 (second case) by extending rG89afec348dbd3e5078f176e978971ee2d3b5dec8

We had coverage for the xor(trunc(xor(x,31)),31) case but not xor(zext(xor(x,31)),31)

Clang test CodeGen/debug-info-extern-call.c tries to check for the
absence of a sequence of instructions with several CHECK-NOT with one of
those directives using a variable defined in another. However CHECK-NOT
are checked independently so that is using a variable defined in a
pattern that should not occur in the input.

This commit removes the CHECK-NOT for the retained line attribute
definition since the CHECK-NOT on the compile unit will already check
that there is no retained lines.

Reviewed By: djtodoro

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

The removal of CAMLprim left the code in need of an application of
clang-format. There are various other changes made by clang-format
which it seems ought to be rolled together into this diff.

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

The CAMLprim macro has not been needed since OCaml 3.11, and is
defined to the empty string. This diff removes all instances of it.

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

The current code does not follow the simple interface to the OCaml GC,
where GC roots are registered conservatively, only initializing
allocations are performed, etc. This is intentional, as stated in the
opening file comments. On the other hand, the current code does
register GC roots in many situations where it is not strictly
necessary. This diff omits many of them.

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

Using the `cstr_to_string` function that allocates and initializes an
OCaml `string` value enables simplifications in several cases. This
change also has the effect of avoiding calling `memcpy` on NULL
pointers even if only 0 bytes are to be copied.

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

Using the `caml_alloc_some` and `ptr_to_option` functions that
allocate OCaml `option` values enables simplifications in many
cases. These simplifications also result in avoiding unnecessary
double initialization in many cases, so yield a minor optimization as
well.

Also, change to avoid using the old unprefixed functions such as
`alloc_small` and instead use the current `caml_alloc_small`.

A few of the changed functions were slightly rewritten in the
early-return style.

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

In several functions an OCaml block is allocated and no further OCaml
allocation functions (or other functions that might trigger allocation
or collection) are performed before the block is fully initialized. In
these cases, it is safe and slightly more efficient to allocate an
uninitialized block.

Also, the code does not become more complex after the non-initializing
allocation, since in the case that a non-small allocation is made, the
initial values stored are definitely not pointers to OCaml young
blocks, and so initializing via direct assignment is still safe. That
is, in general if `caml_alloc_small` is called, initializing it with
direct assignments is safe, but if `caml_alloc_shr` is
called (e.g. for a block larger than `Max_young_wosize`), then
`caml_initialize` should be called to inform the GC of a potential
major to minor pointer. But if the initial value is definitely not a
young OCaml block, direct assignment is safe.

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

Using `Store_field` to initialize fields of blocks allocated with
`caml_alloc_small` is unsafe. The fields of blocks allocated by
`caml_alloc_small` are not initialized, and `Store_field` calls the
OCaml GC write barrier. If the uninitialized value of a field happens
to point into the OCaml heap, then it will e.g. be added to a conflict
set or followed and have what the GC thinks are color bits
changed. This leads to crashes or memory corruption.

This diff fixes a few (I think all) instances of this problem. Some of
these are creating option values. OCaml 4.12 has a dedicated
`caml_alloc_some` function for this, so this diff adds a compatible
function with a version check to avoid conflict. With that, macros for
accessing option values are also added.

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

as requested in https://bugs.llvm.org/show_bug.cgi?id=49553, submitting the proposed changes to just ignore the -flto= options which are recognized by GCC ("auto" and "jobserver").

GCC supports -flto=<auto|jobserver|<N> to select the parallelity for LTO builds. LLVM also has -flto-jobs=<N>, which only seems to have a meaning when used with -flto=thin?

The attached patch just ignores the values "auto" and "jobserver". that doesn't change anything in functionality.  Another option would be to map these values to either "thin" or "full", maybe in presence of the -ffat-lto-objects option?

-flto=<n> could also be translated to -flto-jobs=<N>.

Reviewed By: tejohnson

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

This is to avoid sophistication of checks as the old and new PM behave
differently with fix patches.

Rename it to -fgpu-flush-denormals-to-zero.

Reviewed by: Artem Belevich

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