Remove references to global __kmp_topology within a kmp_topology_t
object method. There should just be implicit references to the
private object.

And remove references to flags to turn it off.

Reviewed By: nikic, MaskRay

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

When we build the library with the stable ABI, we need to include some
functions in the dylib that were made inline in later versions of the
library (to avoid breaking code that might be relying on those symbols).

However, those methods were made non-inline whenever we'd be building
the library, which means that all translation units would end up using
the old out-of-line definition of these methods, as opposed to the new
inlined version. This patch makes it so that only the translation units
that actually define the out-of-line methods use the old definition,
opening up potential optimization opportunities in other translation
units.

This should solve some of the issues encountered in D65667.

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

The LOH pass iterates over instructions to build its custom register
state machine, but it uses the top-level bundle iterator.
This should be okay, because when the wrapper BUNDLE MI is built,
it aggregates the register defs/uses in its instructions into MOs.

However, that doesn't apply to regmasks, and accumulating regmasks
across multiple instructions would be messy business.
There are a couple AnalyzePhysRegInBundle (/Virt) helpers that
do look at regmasks, but those don't fit in very well here.

AArch64 has started to use a few bundle instructions, specifically
as glorified pseudos for variant call instructions, which have regmasks.
So the LOH pass ends up ignoring regmasks.

Concretely, this has been wrong for a while, but, on aarch64, the
most common bundle (rv_marker call) was always followed by the
attached call instruction, a plain BL with a regmask.  Which
was properly detected by the pass.

However, we recently started keeping the attached call in the bundle,
so the regmask is now ignored.  And the pass happily combines ADRPs, of
say, x8, across the bundle, resulting in corrupt pointers later.

This was doing -iphoneos instead of -ios. While there,
remove an old TODO and cleanup some alignment.

This reverts the functional changes of D103427 but keeps its tests, and
and reimplements the functionality by reusing the existing 32-bit
MASKMOVDQU and VMASKMOVDQU instructions as suggested by skan in review.
These instructions were previously predicated on Not64BitMode. This
reimplementation restores the disassembly of a class of instructions,
which will see a test added in followup patch D122449.

These instructions are in 64-bit mode special cased in
X86MCInstLower::Lower, because we use flags with one meaning for subtly
different things: we have an AdSize32 class which indicates both that
the instruction needs a 0x67 prefix and that the text form of the
instruction implies a 0x67 prefix. These instructions are special in
needing a 0x67 prefix but having a text form that does *not* imply a
0x67 prefix, so we encode this in MCInst as an instruction that has an
explicit address size override.

Note that originally VMASKMOVDQU64 was special cased to be excluded from
disassembly, as we cannot distinguish between VMASKMOVDQU and
VMASKMOVDQU64 and rely on the fact that these are indistinguishable, or
close enough to it, at the MCInst level that it does not matter which we
use. Because VMASKMOVDQU now receives special casing, even though it
does not make a difference in the current implementation, as a
precaution VMASKMOVDQU is excluded from disassembly rather than
VMASKMOVDQU64.

Reviewed By: RKSimon, skan

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

[MLIR][Presburger] Remove inheritance from PresburgerSpace in IntegerRelation, PresburgerRelation and PWMAFunction

This patch removes inheritence from PresburgerSpace in IntegerRelation and
instead makes it a member of these classes.

This is required for three reasons:
  - It prevents implicit casting to PresburgerSpace.
  - Not all functions of PresburgerSpace need to be exposed by the deriving classes.
  - IntegerRelation and IntegerPolyhedron are defined in a PresburgerSpace. It
    makes more sense for the space to be a member instead of them inheriting from
    a space.

Reviewed By: arjunp, ftynse

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

Fix path replacement in sed (properly this time) using lit
regex_replacement.

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



Co-authored-by: Michele Scandale <michele.scandale@gmail.com>
Co-authored-by: Zixu Wang <9819235+zixu-w@users.noreply.github.com>

This patch is similar to D122557, adding an `ArrayRef` version for `setOperationAction`, `setLoadExtAction`, `setCondCodeAction`, `setLibcallName`.

Reviewed By: craig.topper

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

Disables image_sample_*_g16 instructions on architectures lacking g16 support. This patch fixes the issue 54672.

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

This renames functions for more general usage (and current capitalization style)
before a proposed logic change in D122485.

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

Fix spelling of variable names and remove accidental references (#)
in Doxygen comments.

Reviewed By: MaskRay, chill

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

In the C++20 Standard time is no longer section under utilities, but
became its own chapter. This moves the time tests accordingly so their
location matches the current Standard.

Reviewed By: ldionne, #libc

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

Use default member initializers in AMDGPUSubtarget and subclasses. This
is to guard against adding a new feature boolean in AMDGPUSubtarget.h
but forgetting to initialize it to false in AMDGPUSubtarget.cpp.

This was mostly autogenerated by:
clang-tidy -checks=-*,cppcoreguidelines-prefer-member-initializer,modernize-use-default-member-init -header-filter=Subtarget -fix lib/Target/AMDGPU/*Subtarget.cpp

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

Folding this case would result in the constant expression being
executed unconditionally, which may introduce a new trap.

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

I have written a minitest to check the performance. Overall
the benefit of aligned b96 operations on data which is not
known but happens to be aligned is small, while performance
hit of using b96 operations on a really unaligned memory is
high.

The only exception is when data is not aligned even by 4, it
is better to use b96 in this case.

Here is the test output on Vega and Navi:

```
Using platform: AMD Accelerated Parallel Processing
Using device: gfx900:xnack-

ds_write_b96                                  aligned: 3.4 sec
ds_write_b32 + ds_write_b64                   aligned: 4.5 sec
ds_write_b32 * 3                              aligned: 4.8 sec
ds_write_b96                          misaligned by 1: 4.8 sec
ds_write_b32 + ds_write_b64           misaligned by 1: 7.2 sec
ds_write_b32 * 3                      misaligned by 1: 10.0 sec
ds_write_b96                          misaligned by 2: 4.8 sec
ds_write_b32 + ds_write_b64           misaligned by 2: 7.2 sec
ds_write_b32 * 3                      misaligned by 2: 10.1 sec
ds_write_b96                          misaligned by 4: 4.8 sec
ds_write_b32 + ds_write_b64           misaligned by 4: 4.2 sec
ds_write_b32 * 3                      misaligned by 4: 4.9 sec
ds_write_b96                          misaligned by 8: 4.8 sec
ds_write_b32 + ds_write_b64           misaligned by 8: 4.6 sec
ds_write_b32 * 3                      misaligned by 8: 4.9 sec
ds_read_b96                                   aligned: 3.3 sec
ds_read_b32 + ds_read_b64                     aligned: 4.9 sec
ds_read_b32 * 3                               aligned: 2.6 sec
ds_read_b96                           misaligned by 1: 4.1 sec
ds_read_b32 + ds_read_b64             misaligned by 1: 7.2 sec
ds_read_b32 * 3                       misaligned by 1: 10.1 sec
ds_read_b96                           misaligned by 2: 4.1 sec
ds_read_b32 + ds_read_b64             misaligned by 2: 7.2 sec
ds_read_b32 * 3                       misaligned by 2: 10.1 sec
ds_read_b96                           misaligned by 4: 4.1 sec
ds_read_b32 + ds_read_b64             misaligned by 4: 2.6 sec
ds_read_b32 * 3                       misaligned by 4: 2.6 sec
ds_read_b96                           misaligned by 8: 4.1 sec
ds_read_b32 + ds_read_b64             misaligned by 8: 4.9 sec
ds_read_b32 * 3                       misaligned by 8: 2.6 sec

Using platform: AMD Accelerated Parallel Processing
Using device: gfx1030

ds_write_b96                                  aligned: 4.1 sec
ds_write_b32 + ds_write_b64                   aligned: 13.0 sec
ds_write_b32 * 3                              aligned: 4.5 sec
ds_write_b96                          misaligned by 1: 12.5 sec
ds_write_b32 + ds_write_b64           misaligned by 1: 22.0 sec
ds_write_b32 * 3                      misaligned by 1: 31.5 sec
ds_write_b96                          misaligned by 2: 12.4 sec
ds_write_b32 + ds_write_b64           misaligned by 2: 22.0 sec
ds_write_b32 * 3                      misaligned by 2: 31.5 sec
ds_write_b96                          misaligned by 4: 12.4 sec
ds_write_b32 + ds_write_b64           misaligned by 4: 4.0 sec
ds_write_b32 * 3                      misaligned by 4: 4.5 sec
ds_write_b96                          misaligned by 8: 12.4 sec
ds_write_b32 + ds_write_b64           misaligned by 8: 13.0 sec
ds_write_b32 * 3                      misaligned by 8: 4.5 sec
ds_read_b96                                   aligned: 3.8 sec
ds_read_b32 + ds_read_b64                     aligned: 12.8 sec
ds_read_b32 * 3                               aligned: 4.4 sec
ds_read_b96                           misaligned by 1: 10.9 sec
ds_read_b32 + ds_read_b64             misaligned by 1: 21.8 sec
ds_read_b32 * 3                       misaligned by 1: 31.5 sec
ds_read_b96                           misaligned by 2: 10.9 sec
ds_read_b32 + ds_read_b64             misaligned by 2: 21.9 sec
ds_read_b32 * 3                       misaligned by 2: 31.5 sec
ds_read_b96                           misaligned by 4: 10.9 sec
ds_read_b32 + ds_read_b64             misaligned by 4: 3.8 sec
ds_read_b32 * 3                       misaligned by 4: 4.5 sec
ds_read_b96                           misaligned by 8: 10.9 sec
ds_read_b32 + ds_read_b64             misaligned by 8: 12.8 sec
ds_read_b32 * 3                       misaligned by 8: 4.5 sec
```

Fixes: SWDEV-330802

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

Move features/bugs checks into the single place
allowsMisalignedMemoryAccessesImpl.

This is mostly NFCI except for the order of selection in couple places.
A separate change may be needed to stop lying about Fast.

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

Most of the getTargetShuffleInputs recursive calls have now gone and the remaining uses aren't likely to benefit from a DemandedElts mask

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

Reviewed By: aaron.ballman

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

The __size_ member is now in a slightly different location.

Don't warn on unknown type attributes in Parser::ProhibitCXX11Attributes
for most cases, but left the diagnostic to the later checks.
module declaration and module import declaration are special cases.

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

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

During strlen compile-time evaluation, make it possible to track size of
strduped strings.

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

This means we don't have to remember to update this code as much.

This is all tested in lldb/test/Shell/Commands/command-disassemble-aarch64-extensions.s
which I added previously.

We don't have a way to get the latest base architecture yet
so that remains manual. Having all the extensions specified
will probably be equivalent to the latest architecture version
in any case.

Reviewed By: labath

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

The description has been updated to reflect AMDGPU MC changes:
- enabled literals for src0 of v_fmaak_f*, v_fmamk_f*, v_madak_f32, v_madmk_f32;
- enabled global_atomic_fcmpswap and global_atomic_fcmpswap_x2;
- enabled dlc with flat_atomic* and global_atomic_*.

Bug fixing and improvements:
- enabled s_wait_idle;
- enabled s_waitcnt_depctr;
- added description of s_waitcnt_depctr syntactic sugar;
- disabled SYSMSG_OP_HOST_TRAP_ACK (it is not supported on GFX10);
- corrected description of lgkmcnt (accept values from 0 to 63).

Summary of changes:
- enabled null for VOP operands;
- added description of s_waitcnt_depctr syntactic sugar.

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

This is unncessary, so we remove it as an optimization.

Reviewed By: Groverkss

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

It breaks arm build, there is no free bit for the extra
UsingShadowDecl in TemplateName::StorageType.

Reverting it to build the buildbot back until we comeup with a fix.

This reverts commit 5a5be404.

With this change, there's going to be a clear distinction between LLVM
and MLIR pass maanger options (e.g. `-mlir-print-after-all` vs
`-print-after-all`). This change is desirable from the point of view of
projects that depend on both LLVM and MLIR, e.g. Flang.

For consistency, all pass manager options in MLIR are prefixed with
`mlir-`, even options that don't have equivalents in LLVM .

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

Lookup iter_arg buffers using `lookupBuffer` instead of always creating a new `ToMemrefOp`. Also cast all yielded buffers (if necessary), regardless of whether they are an equivalent buffer or a new allocation.

Note: This should have been part of D123369.

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