This sets the `MLIR_PDLL_TABLEGEN_EXE` and `MLIR_PDLL_TABLEGEN_TARGET`
as cache variables which is necessary for cross-compiling projects that
rely on MLIR and the mlir-pdll-tblgen tool.

The patch is similar to https://reviews.llvm.org/D130350.

Reviewed By: jpienaar

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

This works with the automatic export of all symbols; in MinGW mode,
when a DLL has no explicit dllexports, it exports all symbols (except
for some that are hardcoded to be excluded, including some toolchain
libraries).

By hooking up the hidden visibility to the -exclude-symbols: directive,
the automatic export of all symbols can be controlled in an easier
way (with a mechanism that doesn't require strict annotation of every
single symbol, but which allows gradually marking more unnecessary
symbols as hidden).

The primary use case is dylib builds of LLVM/Clang. These can be done
in MinGW mode but not in MSVC mode, as MinGW builds can export all
symbols (and the calling code can use APIs without corresponding
dllimport directives). However, as all symbols are exported, it can
easily overflow the max number of exported symbols in a DLL (65536).

In the llvm-mingw distribution, only the X86, ARM and AArch64 backends
are enabled; for the LLVM 13.0.0 release, libLLVM-13.dll ended up with
58112 exported symbols. For LLVM 14.0.0, it was 62015 symbols. Current
builds of the 15.x branch end up at around 64650 symbols - i.e. extremely
close to the limit.

The msys2 packages of LLVM have had to progressively disable more
of their backends in their builds, to be able to keep building with a
dylib.

This allows improving the current mingw dylib situation significantly,
by using the same hidden visibility options and attributes as on Unix.
With those in place, a current build of LLVM git main ends up at 35142
symbols instead of 64650.

For code using hidden visibility, this now requires linking with either
a current git lld or ld.bfd. (Older lld error out on the unknown
directives, older ld.bfd will successfully link, but will print huge
amounts of warnings.)

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

This is an entirely new embedded directive - extending the GNU ld
command line option --exclude-symbols to be usable in embedded
directives too.

(GNU ld.bfd also got support for the same new directive, currently in
the latest git version, after the 2.39 branch.)

This works as an inverse to the regular embedded dllexport directives,
for cases when autoexport of all eligible symbols is performed.

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

This adds support for the existing GNU ld command line option, which
allows excluding individual symbols from autoexport (when linking a
DLL and no symbols are marked explicitly as dllexported).

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

Expand TypePromotion pass to try to promote PHI-nodes in loops that are the
operand of a ZExt, using the ZExt's result type to determine the Promote Width.

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

Hoist out promote width calculation to simplify runOnFunction.

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

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

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

Other sanitizers (ASan, TSan, see added tests) already handle
memcpy.inline and memset.inline by not relying on InstVisitor to turn
the intrinsics into calls. Only MSan instrumentation currently does not
support them due to missing InstVisitor callbacks.

Fix it by actually making InstVisitor handle Mem*InlineInst.

While the mem*.inline intrinsics promise no calls to external functions
as an optimization, for the sanitizers we need to break this guarantee
since access into the runtime is required either way, and performance
can no longer be guaranteed. All other cases, where generating a call is
incorrect, should instead use no_sanitize.

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

Reviewed By: vitalybuka, dvyukov

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

c7ec6e19 made LLVM adhere to the x86
psABI and pass bf16 in SSE registers instead of GPRs. This breaks the
custom versions of runtime functions we have for bf16 conversion. A
great fix for this would be to use __bf16 types instead which carry the
right ABI, but that type isn't widely available.

Instead just pretend it's a 32 bit float on the ABI boundary and
carefully cast it to the right type.

Fixes #57042

Functionally broken code for reading and writing registers, likely due to typos,
and could cause out-of-bounds memory access.

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

Flags uses of const-qualified and reference data members in structs.
Implements rule C.12 of C++ Core Guidelines.

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

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

This fixes the following warnings produced by GCC 9:

In file included from ../tools/clang/include/clang/Sema/ExternalSemaSource.h:15,
                 from ../tools/clang/include/clang/Sema/HLSLExternalSemaSource.h:17,
                 from ../tools/clang/lib/Sema/HLSLExternalSemaSource.cpp:12:
../tools/clang/include/clang/AST/ExternalASTSource.h:211:16: warning: ‘virtual void clang::ExternalASTSource::CompleteType(clang::ObjCInterfaceDecl*)’ was hidden [-Woverloaded-virtual]
  211 |   virtual void CompleteType(ObjCInterfaceDecl *Class);
      |                ^~~~~~~~~~~~
In file included from ../tools/clang/lib/Sema/HLSLExternalSemaSource.cpp:12:
../tools/clang/include/clang/Sema/HLSLExternalSemaSource.h:49:8: warning:   by  virtual void clang::HLSLExternalSemaSource::CompleteType(clang::TagDecl*)’ [-Woverloaded-virtual]
   49 |   void CompleteType(TagDecl *Tag) override;
      |        ^~~~~~~~~~~~

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

Since bb939931, the c++experimental
library is always built, so these tested files should always be built
(even if they aren't used in tests).

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

Try to fix these errors:

SemaDeclCXX.cpp:16666:19: error: declaration of ‘const clang::Expr* clang::Sema::DiagnoseStaticAssertDetails(const clang::Expr*)::<unnamed struct>::Expr’ changes meaning of ‘Expr’ [-fpermissive]
16666 |       const Expr *Expr;
      |                   ^~~~

Reduces runtime of the test.
Unrelated pre-merge checks often timeouts here.

This silences the following warnings:

../include/llvm/ExecutionEngine/JITLink/JITLink.h:1108:56: warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]
 1105 |     assert(S == Scope::Local || llvm::count_if(AbsoluteSymbols,
      |                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 1106 |                                                [&](const Symbol *Sym) {
      |                                                ~~~~~~~~~~~~~~~~~~~~~~~~
 1107 |                                                  return Sym->getName() == Name;
      |                                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 1108 |                                                }) == 0 &&
      |                                                ~~~~~~~~^~
 1109 |                                     "Duplicate absolute symbol");
      |                                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~

I noticed this when adding a new type to the index for
https://github.com/clangd/clangd/issues/529. When the assertion failed,
this actually caused a crash, because llvm::expected would complain that
we did not take the error.

For failed static assertions, try to take the expression apart and print
useful information about why it failed. In particular, look at binary
operators and print the compile-time evaluated value of the LHS/RHS.

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

Introduces COFFVCRuntimeBootstrapper that loads/initialize vc runtime libraries. In COFF, we *must* jit-link vc runtime libraries as COFF relocation types have no proper way to deal with out-of-reach data symbols ragardless of linking mode. (even dynamic version msvcrt.lib have tons of static data symbols that must be jit-linked) This class tries to load vc runtime library files from msvc installations with an option to override the path.

There are some complications when dealing with static version of vc runtimes. First, they need static initializers to be ran that requires COFFPlatform support but orc runtime will not be usable before vc runtimes are fully initialized. (as orc runtime will use msvc stl libraries) COFFPlatform that will be introduced in a following up patch will collect static initializers and run them manually in host before boostrapping itself. So, the user will have to do the following.
1. Create COFFPlatform that addes static initializer collecting passes.
2. LoadVCRuntime
3. InitializeVCRuntime
4. COFFPlatform.bootstrap()
Second, the internal crt initialization function had to be reimplemented in orc side. There are other ways of doing this, but this is the simplest implementation that makes platform fully responsible for static initializer. The complication comes from the fact that crt initialization functions (such as acrt_initialize or dllmain_crt_process_attach) actually run all static initializers by traversing from `__xi_a` symbol to `__xi_z`. This requires symbols to be contiguously allocated in sections alphabetically sorted in memory, which is not possible right now and not practical in jit setting. We might ignore emission of `__xi_a` and `__xi_z` symbol and allocate them ourselves, but we have to take extra care after orc runtime boostrap has been done -- as that point orc runtime should be the one running the static initializers.

Reviewed By: lhames

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

Added:
- Take RISC-V `ebreak` instruction as breakpoint trap code, so our breakpoint works as expected now.

Further work:
- RISC-V does not support hardware single stepping yet. A software implementation may come in future PR.
- Add support for RVC extension (the trap code, etc.).

Reviewed By: DavidSpickett

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

Update the DR status page with the C++ Standard Core
Issues List revision 109.

This patch is based on the minimal extract of D128250.

What is implemented:
- Use the same register layout as Linux kernel and mock read/write for `x0` register (the always zero register).
- Refactor some duplicate code, and delete unused register definitions.

Reviewed By: DavidSpickett

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

Stubs SECREL relocation to external symbol. In order to correctly deal with this, we want to requrest memory manager to keep track of address of first block of sepecific section and keep address to be only increased from that point. We also should give jitlink to get information about global section. The relocation is only used for debug and tls info which we don't support yet anyways, so just stubbing it for now.

Reviewed By: lhames

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

Implements SECTION/SECREL relocation. These are used by debug info (pdb) data.

Reviewed By: lhames

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

Right now we can only add a single warning, notes are not possible.

Apparently some provisions were made to allow notes, but they were never
propagated all the way to the diagnostics.

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

Precommitted test cases for D130442.

Reviewed By: craig.topper

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

Summary: AIX XCOFF doesn't support the cold feature.
    While it shouldn't be a function error when XCOFF catching the cold attribute.
    As with the behavior of other formats, we just ignore the attribute for now.

Reviewed By: DiggerLin

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

This is not used as general CPU alias. Only to support -mtune. Name it as such.

Reviewed By: kito-cheng

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

This patch makes the variants of `mm*_cast*` intel intrinsics that use `shufflevector(freeze(poison), ..)` emit efficient assembly.
(These intrinsics are planned to use `shufflevector(freeze(poison), ..)` after shufflevector's semantics update; relevant thread: D103874)

To do so, this patch

1. Updates `LowerAVXCONCAT_VECTORS` in X86ISelLowering.cpp to recognize `FREEZE(UNDEF)` operand of `CONCAT_VECTOR` in addition to `UNDEF`
2. Updates X86InstrVecCompiler.td to recognize `insert_subvector` of `FREEZE(UNDEF)` vector as its first operand.

Reviewed By: craig.topper

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