The generalization pattern for tensor.pack was inverting the
innerDimsPos permutation when normalizing. Thus, the transpose op
produced by the generalization would be incorrect.

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

Reviewed By: vitalybuka

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

This reverts commit 8217932a.

Breaks buildbots.

Create writer for new JSON format.
The new JSON format allows practically all attributes to be defined per
target in a universal library however the internal representation only
allows one for the time being. For now the write will always write those
attributes as default available for all targets (install name,
compatability & current version, swift abi, flags e.g. flatnamepace &
app exenstion safety)

rdar://102076911

Reviewed By: ributzka

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

This came out of from https://discourse.llvm.org/t/dwarf-dwp-4gb-limit/63902
With big binaries we can have .dwp files where .debug_info.dwo section can grow
beyond 4GB. We would like to support this in LLVM and in LLDB.

The plan is to enable manual parsing of cu/tu index in DWARF library
(https://reviews.llvm.org/D137882), and then
switch internal index data structure to 64 bit.
For the second part is to enable 64bit offset support in LLDB with
this patch.

Reviewed By: labath

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

This patch implements vectorization of tensor.extract for n-D tensor (n
>= 2) using contiguous load operations, i.e. `vector.transfer_read`. This
is a follow-up of https://reviews.llvm.org/D137660 in which gather loads
were used, i.e. `vector.gather`.

It is always safe to use gather load operations when the underlying
memory pattern is contiguous, but not vice-verse. At the moment, the
following conditions have to be met for contiguous loads to be
generated:
  1. The _output tensor_ must be a 1-D vector with the trailing dim > 1,
     e.g. `tensor<1x1x4xi32`,
  2. The trailing dim in the _input tensor_ must be > 1, e.g.
     `tensor<1x1x4i32>` would be fine, but not `tensor<1x4x1xi32>`.
If these conditions are not satisfied, gather loads are generated
instead.

Condition 1 guarantees that the iteration space of the corresponding
`linalg.generic` Op is relatively simple. That makes analysing the
indices for `tensor.extract` rather straightforward.

Condition 2 is mostly there to avoid weird vectorisation patterns
resulting in vectors like: `vector<1x1x1xi32>`. In practice, tensors
like `tensor<1x4x1xi32>` should be collapsed to `tensor<1x4xi32>` before
vectorisation, but that's beyond the scope of this patch.

If needed, both conditions can be relaxed. I've not been able to find a
good motivating example for these, hence skipping. For reference,
`tosa.resize` (lowered to Linalg) was the driving example used here.

As a bonus, the test from "vectorization-unsupported.mlir" is moved to
"vectorization.mlir" with proper CHECK lines added.

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



Co-authored-by: Diego Caballero <diegocaballero@google.com>

This patch adds a partial implementation of `quick_exit` for the GPU
target. This is mainly done to test object libraries for the GPU and
will be expanded later. This will simply cause the threads to terminate
on the GPU without returning an error code. This functionality will be
added later to facilitate unit tests.

Reviewed By: sivachandra

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

A single class allows multiple categories to be defined for it. But if
two of such categories have the same name, we emit a warning. It's not a
hard error but a good indication of a potential mistake.

With modules, we can end up with the same category in different modules.
Diagnosing such a situation has little value as the categories in
different modules are equivalent and don't reflect the usage of the same
name for different purposes. When we deserialize a duplicate category,
compare it to an existing one and warn only when the new one is
different.

rdar://104582081

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

65420c80 introduced an ICE in combineMinNumMaxNum(...) when
combineMinNumMaxNumImpl(...) returns an SDValue(). Make sure to check that a
value is returned before trying to perform an FNEG on it.

GitHub Issue: #60924

Reviewed By: arsenm

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

A mistake in the control flow of performMemPairCombine resulted in paired
loads/stores for types that were not supported by the instructions (i8/i16).
These loads/stores could not match the constraints of the patterns defined
in the THead td file and the compiler would throw a 'Cannot select' error.

This is now fixed and two new test functions have been added in xtheadmempair.ll
which would previously crash the compiler. The compiler was additionally tested
with a wide range of benchmarks and no issues were observed.

Reviewed By: craig.topper

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

Per spec:

https://pubs.opengroup.org/onlinepubs/9699919799/functions/ntohl.html
https://pubs.opengroup.org/onlinepubs/9699919799/functions/ntohs.html



Co-authored-by: Jeff Bailey <jbailey@google.com>

Reviewed By: sivachandra

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

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

Not entirely sure we'll end up reusing the body of the transform, but personally I find this structure easier to follow anyways.

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

This reverts commit 451799bb.

Causes crashes, see D139209

Summary:
Currently AMDGPU only barely supports cross-TU ELF linking. Full linking
is usually done via LTO. This requires passing the architecture to the
link job. This is done automatically via `-flto` since D144505. Add this
to the link options.

This reverts commit efae3174 since
it broke the standalone Flang build.

[AMDGPU] Improve the lowering of raw_buffer_load_{i8,i16} and struct_buffer_load_{i8,i16} intrinsics

Currently, raw_buffer_load_{i8,i16} and struct_buffer_load_{i8,i16}
intrinsics are lowered as buffer_load_{u8,u16}. This patch combines
buffer_load_{u8,u16} and sign extension instructions in order to
generate buffer_load_{i8,i16} instructions.

Reviewed By: foad

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

The module flag "debug-info-assignment-tracking" is set by the
declare-to-assign pass to indicate that assignment tracking is enabled. This
patch changes declare-to-assign to only set the flag if it makes a
modification. This lets the compiler avoid doing extra work for no benefit,
such as is currently the case if assignment tracking is requested for a build
with line tables only (-gmlt) or a build without debug info.

Reviewed By: scott.linder

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

v_permlane16_b32 and v_permlanex16_b32 should not set abs and neg src
modifiers on any input, but they can set op_sel on src0 or src1 to
represent fi or bc when desired. The ISel patterns were setting
the src_modifier bits to -1, effectively setting abs and neg as well,
whenever it was intended to set op_sel, due to an error in ISel. ISel
should now correctly only set the op_sel bits.

Reviewed By: arsenm

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

Enabling assignment tracking without this patch, a significant amount of
additional compiler run time comes from the RemoveRedundantDbgInstrs call in
InstCombine. This patch reduces compiler run time by choosing better places to
call RemoveRedundantDbgInstrs.

In non-assignment-tracking builds, RemoveRedundantDbgInstrs is called by
InstCombine if LowerDbgDeclare makes a change (i.e. it is _sometimes_
called). In assignment tracking builds LowerDbgDeclare doesn't do anything. We
still need to clean up redundant intrinsics to avoid a large performance hit
due to the number of instructions, so the current approach is to have
InstCombine _always_ call RemoveRedundantDbgInstrs.

Instrumenting the compiler to run RemoveRedundantDbgInstrs after every pass and
dump the numbers and building CTMark/tramp3d-v4 indicates that SROA and
LoopVectorize give us a bigger bang (number removed) for buck (times pass is
run).

The compile time tracker reports that this patch reduces the number of
instructions retired building CTMark projects by an average of 1.1%.

Reviewed By: scott.linder

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

Moving this out of AMDGPUBaseInfo enforces that AMDGPUBaseInfo should
not be calling into GCNSubtarget.

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

Reviewed By: #libc, philnik

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

After reading about the documentation improvements on LLVM weekly this
part seems obsolete.

Reviewed By: ChuanqiXu

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

The AMDGPU toolchain support directly compiling GPU images using
cross-compilation such as `clang --target=amdgcn-amd-amdhsa foo.c`.
However, when attempting to link bitcode this does not work because the
`-mcpu` options are not forwarded to the linker among others. This patch
simply adds them so that `clang --target=amdgcn-amd-amdhsa foo.c -flto`
works correctly.

Reviewed By: JonChesterfield

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

These shouldn't really reach SCEV without being folded away first,
and we don't have any tests that hit these cases.

The sizeof case does occur with scalable types.

This change matches the CUDA/SPIRV behavior with CUDA/NVPTX, and makes some builtin types
and __GCC_ATOMIC_XXX_LOCK_FREE macros the same between the host and device. This is only
done when host triple is provided and known, otherwise the behavior is unchanged.

Reviewed By: yaxunl

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

This change silences a compiler warning: `base class should be explictily initialized in the copy constructor`.

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

These checks show optimized instructions if an operand is known to be
(partially) zero.

Change-Id: Ie2f6d0d3ee9d5b279d1f4c1dd0787492e39cc77a

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

This is in preparation for https://reviews.llvm.org/D129857.

This is for consistency with `Value::replaceUsesWithIf`.

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

This patch achieves this by building an AST and invoking main file
callbacks on each update, in addition to preamble updates.

It means we might have some extra AST builds now (e.g. if an update was
with a stale preamble and there were no reads on it, we would only build
an AST once we had the fresh preamble. Now we'll build 2, once with the
stale preamble and another with the fresh one, but we'll have one more
diagnostics cycle in between.).

This patch preserves forward progress of diagnostics by always using the
latest main file contents when emitting diagnostics after preamble
builds. It also guarantees eventual consistency:
- if an update doesn't invalidate preamble, we'll emit diagnostics with
  fresh preamble already.
- if an update invalidates preamble, we'll first emit diagnostics with
  stale contents, and then once the preamble build finishes it'll emit
  diagnostics (as preamble has changed) with newest version.

This has implications on parsing callbacks, as previously onMainAST
callback was called at most once, now it can be called up to 2 times.
All of the existing clients can already deal with callback firing
multiple times.

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

Translates diagnostics from baseline preamble to relevant modified
contents.

Translation is done by looking for a set of lines that have the same
contents in diagnostic/note/fix ranges inside baseline and modified
contents.

A diagnostic is preserved if its main range is outside of main file or
there's a translation from baseline to modified contents. Later on fixes
and notes attached to that diagnostic with relevant ranges are also
translated and preserved.

Depends on D143095

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

Depends on D143093

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

That way we can stop generating false macro redefinition diagnostics.

Depends on D142890

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

Also wire it up for use with patched preambles and introduce test cases
for behaviour we'd like to improve.

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

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

The function arguments and results type will have the default memory space.

Reviewed By: springerm

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

When the associated expression came from a moved variable, the
type of the moved variable may not exactly match the hlfir.associate
result and cannot be re-used directly. Insert fir.convert/fir.box_addr
as needed.

Reviewed By: clementval

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