Check that vreg_width-1 mask is only removed for shifts

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

We can replace several "let AsmString =".

For more details about these instructions, please refer to the latest ISE document: https://www.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

Reviewed By: pengfei, skan

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

StringMap iteration order is not guaranteed to be deterministic
(https://llvm.org/docs/ProgrammersManual.html#llvm-adt-stringmap-h).

Tested by `TEST_F(InMemoryFileSystemTest, DirectoryIteration)`.

This gives us a common place to put the TSFlags and the Namespace.

Removes TSFlags declaration duplication for D155690.

Reviewed By: wangpc

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

StringMap iteration order is not guaranteed to be deterministic
(https://llvm.org/docs/ProgrammersManual.html#llvm-adt-stringmap-h).

Similar to the llvm::sort call in DebugMapObject::print.

Currently CUDA/HIP defines their own language standards in
LanguageStandards.def but they are redundant. They are the same as stdc++14.
The fact that CUDA/HIP uses c++* in option -std= indicates that they have the
same language standards as C++. The CUDA/HIP specific language features are
conveyed through language options, not language standards features. It makes
sense to let CUDA/HIP uses the same default language standard as C++.

Reviewed by: Siu Chi Chan, Artem Belevich

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

Fixes: SWDEV-407685

This reverts commit c9953d98 and a
forward fix in 3a45b843.

D14677 causes some failure on windows bots that the forward fix did not
address. Thus I'm reverting until the underlying cause can me triaged.

The test cases for selecting increasing integer induction variable.

Reviewed By: fhahn, shiva0217

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

Use a MapVector to stabilize the order and simplify future changes like
D142862 that change the StringMap hash function.

Entries of the same DJB hash are in the hash lookup table/name table are
ordered by the iteration order of `Entries` (a StringMap). Change
`Entries` to a MapVector to stabilize the order and simplify future
changes like D142862 that change the StringMap hash function.

Co-authored-by: Paul Scoropan <1paulscoropan@gmail.com>

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

For more details about these instructions, please refer to the latest ISE document: https://www.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

Reviewed By: pengfei

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

Moves the llvm-jitlink tool statistics out of the Session struct and into a new
LLVMJITLinkStatistics class.

Also removes the `-show-sizes` option. Each statistic added will now have its
own option. The two previous stats (total size of all blocks before pruning and
after fixups) are now available as -pre-prune-total-block-size and
-post-fixup-total-block-size.

This change should make it easier to add new statistics.

For more details about this instruction, please refer to the latest ISE document: https://www.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

Reviewed By: RKSimon, skan

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

Chunk size decided by the thread count makes the UUID less deterministic
(e.g. across machines with different core counts.)
Follow ELF and just use a fixed chunksize.

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

Reviewed By: #lld-macho, keith

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

Simplify future changes like D142862 that change the hash function.

For real this time.

I have yet again broken ppcbe. This should fix it.

When LLVM is built under MSVC and libcxx ABI is set to 2, the
'copy_move.pass' test will unexpectedly pass. This patch mitigate
this issue by setting this test will only expecting FAIL when libcxx
ABI version is set to 1.

This is a re-land of be9f55f4

Differential Revision: https://reviews.llvm.org/D155760
Fixes: https://github.com/llvm/llvm-project/issues/63442

We don't support this as a argument or return type, it's always promoted to <2 x s32>.

Performing the widening prevents us from having selection failures due to unsupported
extends.

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

Since UUID generation in lld is fast this is rarely used but it can be
helpful to avoid temporary issues like https://github.com/llvm/llvm-project/issues/63961

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

This reverts commit be9f55f4.

The commit was both not approved by the libc++ review group, and also
the only change it contained was incorrect.

This changes the definition if `isSectionBitcode` to only be valid for the
`.llvm.lto` section, since this API is only called from LTO, and the
`.llvmbc` section was not intended to be used for LTO. This allows the
gold plugin to keep its existing behavior without introducing any
significant changes.

Depends on D146778

Reviewed By: MaskRay

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

This patch adds support to lld for --fat-lto-objects. We add a new
--fat-lto-objects flag to LLD, and slightly change how it chooses input
files in the driver when the flag is set.

Fat LTO objects contain both LTO compatible IR, as well as generated object
code. This allows users to defer the choice of whether to use LTO or not to
link-time. This is a feature available in GCC for some time, and makes the
existing -ffat-lto-objects flag functional in the same way as GCC's.

If the --fat-lto-objects option is passed to LLD and the input files are fat
object files, then the linker will chose the LTO compatible bitcode sections
embedded within the fat object and link them together using LTO. Otherwise,
standard object file linking is done using the assembly section in the object
files.

Original RFC: https://discourse.llvm.org/t/rfc-ffat-lto-objects-support/63977

Depends on D146777

Reviewed By: MaskRay

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

When writing this initially I missed including the resource stride.
This change adds the resources stride to the serialized value.

I've also extended the testing and error reporting around parsing PSV
information. This adds tests to verify that the reader produces
meaningful error messages for malformed DXContainer files, and a test
that verifies the resource stride is respected in the reader even if
the stride isn't an expected or known value (as would happen if the
format changes in the future).

This is part of #59479.

Reviewed By: bogner, bob80905

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

https://reviews.llvm.org/rG8acdcf4016876d122733991561be706b64026e73 didn't include handling for the fact that `throw`'s implementation takes a pointer to a type's `typeinfo` struct, which implies that its signature needs to change as well. This corrects that and adds a test.

Reviewed By: rjmccall

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

When LLVM is built under MSVC and libcxx ABI is set to 2, the
'copy_move.pass' test will unexpectedly pass. This patch mitigate this
issue by setting this test will only expecting FAIL when libcxx ABI
version is set to 1.

Differential Revision: https://reviews.llvm.org/D155760
Fixes: https://github.com/llvm/llvm-project/issues/63442

Looks like a couple of flang bots are broken by this change. Reverting
to investigate.

This reverts commit b2eda85f.

Following recent changes switching from xxh64 to xxh32 for better
hashing performance (e.g., D154813). I am not familiar with this use
case, but this change will ensure that the lld executable doesn't need
xxHash64 after wasm-ld migrates.

When we have both explicitly included and excluded option sets, we
were excluding anything from the latter set regardless of what was in
the former. This doesn't compose well and led to an overly complicated
design around DXC options where a third flag was introduced to handle
options that overlapped between DXC and CL.

With this change we check the included options before excluding
anything from the exclude list, which allows for options that are in
multiple categories to be handled in a sensible way. This allows us to
remove CLDXCOption but should otherwise be NFC.

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