PR47686. These micro-architecture levels are defined in the x86-64 psABI:

https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/77566eb03bc6a326811cb7e9

GCC 11 will support these levels.

Note, -mtune=x86-64-v[234] are invalid and __builtin_cpu_is cannot be
used on them.

Reviewed By: craig.topper, RKSimon

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

This patch upstream the lowering of Parallel construct that was initially done in
https://github.com/flang-compiler/f18-llvm-project/pull/460.

Reviewed By: jeanPerier

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

This patch update the loop construct lowring to match fir-dev changes.

Reviewed By: jeanPerier

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

There's no need to create constant vector splats manually.

Consistently use the original shift instruction's Type/BitWidth instead of the operands, casted values etc.

This restores commit ab1b4810 which was
reverted in 01b9deba, with a fix for the
issue it caused. We should use a temporary BitstreamCursor when
loading the global decl attachment records so that the abbrev ids held
in the lazy loading IndexCursor are not clobbered. Enhanced the test so
that the issue is exposed there.

Original description:

When performing ThinLTO importing, the metadata loader attempts to lazy
load, by building an index. However, module level global decl attachment
metadata was being parsed early while building the index, since the
associated (module level) global values aren't materialized on demand.
This results in the creation of forward reference temporary metadatas,
which are expensive.

Normally, these module level global values don't have much attached
metadata. However, in the case of -fwhole-program-vtables (e.g. for
whole program devirtualization), the vtables may have many attached type
metadatas. This was resulting in very slow performance when performing
ThinLTO importing with the default lazy loading.

This patch restructures the handling of these global decl attachment
records, delaying their parsing until after the lazy loading index has
been built. Then the parser can use the interface that loads from the
index, which resolves forward references immediately instead of creating
expensive temporaries.

For one ThinLTO backend that imports from modules containing huge
numbers of vtables and associated types, I measured the following
compile times for the metadata materialization during function
importing, rounded to nearest second:

No -fwhole-program-vtables:
  Lazy loading on (head):  1s
  Lazy loading off (head): 3s
  Lazy loading on (patch): 1s

With -fwhole-program-vtables:
  Lazy loading on (head):  440s
  Lazy loading off (head): 4s
  Lazy loading on (patch): 2s

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

This patch turns VPMemoryInstructionRecipe into a VPValue and uses it
during VPlan construction and codegeneration instead of the plain IR
reference where possible.

Reviewed By: dmgreen

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

Jeremy Morse discovered an issue with the lit test introduced in D88363. The
test gives different results for Sony's `-O1`.

The test needs to run at `-O1` otherwise the likelihood attribute will be
ignored. Instead of running all `-O1` passes it only runs the lower-expect pass
which is needed to lower `__builtin_expect`.

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

Noticed by Peter Foley.
In glibc, ::write is declared as __attribute__((__warn_unused_result__)) when __USE_FORTIFY_LEVEL is larger than 0.

Revert 1c021c64 "[SCEV] Model ptrtoint(SCEVUnknown) cast not as unknown, but as zext/trunc/self of SCEVUnknown"

> While we indeed can't treat them as no-ops, i believe we can/should
> do better than just modelling them as `unknown`. `inttoptr` story
> is complicated, but for `ptrtoint`, it seems straight-forward
> to model it just as a zext-or-trunc of unknown.
>
> This may be important now that we track towards
> making inttoptr/ptrtoint casts not no-op,
> and towards preventing folding them into loads/etc
> (see D88979/D88789/D88788)
>
> Reviewed By: mkazantsev
>
> Differential Revision: https://reviews.llvm.org/D88806

It caused the following assert during Chromium builds:

  llvm/lib/IR/Constants.cpp:1868:
  static llvm::Constant *llvm::ConstantExpr::getTrunc(llvm::Constant *, llvm::Type *, bool):
  Assertion `C->getType()->isIntOrIntVectorTy() && "Trunc operand must be integer"' failed.

See code review for a link to a reproducer.

This reverts commit 1c021c64.

If the known shift amount is bigger than or equal to the bitwidth of the type of the value to be shifted,
the result is target dependent, so don't try to infer any bits.

This fixes a crash we've seen in one of our internal test suites.

Reviewed By: arsenm

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

The change starts from LiveRangeMatrix and also checks the users of the
APIs are typed accordingly.

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

Now that operands of the recipe are managed through VPUser, we can
simplify the printing by just using the operands.

It's never null - the reason it's modeled as a pointer is because the
pass can't init it in its ctor. Passing by ref simplifies the code, too,
as the null checks were unnecessary complexity.

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

If the metadata is valid yaml, we can print it, even if it failed
validation. That makes it easier to debug any wrong metadata.

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

60b85209 introduced SCEV verification to
deleteDeadLoop, but it appears this check is currently a bit over-eager
and some users of deleteDeadLoop appear to only patch up SE after
calling it (e.g. PR47753).

Remove the extra check for now. We can consider adding it back after we
tracked down the source of the inconsistency for PR47753.

Extend loadSRsrcFromVGPR to allow moving a range of instructions into
the loop. The call instruction is surrounded by copies into physical
registers which should be part of the waterfall loop.

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

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

[InstCombine] matchFunnelShift - fold or(shl(a,x),lshr(b,sub(bw,x))) -> fshl(a,b,x) iff x < bw (REAPPLIED)

If value tracking can confirm that a shift value is less than the type bitwidth then we can more confidently fold general or(shl(a,x),lshr(b,sub(bw,x))) patterns to a funnel/rotate intrinsic pattern without causing bad codegen regressions in the backend (see D89139).

Reapplied after the shift canonicalization in rG02295e6d which removed the need to flip the shift values.

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

After rG02295e6d we no longer need to invert the shift values for fshr - this is just hidden at the moment as funnel shifts only ever match for constant values so never use the fshr "Sub on SHL" path.

Simplify the shift amount matching code by canonicalizing the shift ops first.

https://sourceware.org/gdb/current/onlinedocs/gdb/Host-I_002fO-Packets.html

States that all numbers should be hexidecimal but lldb
uses decimals in vFile:pread and vFile:pwrite.

lldb-server can accept either since it ends up using
strtoull which will detect the base being used.

Reviewed By: labath

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

The test fails on clang-ppc64le-rhel buildbot, needs further
investigation.

Full set case is handled inside intersection, no need to
litter the code with duplicating them outside.

Depends on D88415

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

File-granular information is considered details.

Depends on D88411

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

File-granular information is considered details.

Depends on D88411

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

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

A structure that can be used to represent memory usage of a nested
set of systems.

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

Based on a discussion on D88783, if we're promoting a funnel shift to a width at least twice the size as the original type, then we can use the 'double shift' patterns (shifting the concatenated sources).

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

Reviewed By: herhut

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

VE doesn't have instruction for copysign, so expand it.  Add a
regression test also.

Reviewed By: simoll

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

This is essentially a replacement for the PacketUnimplementedError
previously present in the gdb-remote server code.

The reason I am introducing a generic error is because I wanted the
native process classes to be able to signal that they do not support
some functionality. They could not use PacketUnimplementedError as they
are independent of a specific transport protocol. Putting the error
class in the the native process code was also not ideal because the
gdb-remote code is also used for lldb-server's platform mode, which does
not (should not) know how to debug individual processes.

I'm putting it under Utility, as I think it can be generally useful for
notifying about unsupported/unimplemented functionality (and in
particular, for programatically testing whether something is
unsupported).

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