At the moment, Clang only considers errno when deciding if a builtin
is const. This ignores the fact that some library functions may raise
floating point exceptions, which may modify global state, e.g. when
updating FP status registers.

To model the fact that some library functions/builtins may raise
floating point exceptions, this patch adds a new 'g' modifier for
builtins. If a builtin is marked with 'g', it cannot be considered
const, unless FP exceptions are ignored.

So far I've not added CHECK lines for all calls in math-libcalls.c. I'll
do that once we agree on the overall direction.

A consequence seems to be that we fail to select some of the constrained
math builtins now, but I am not entirely sure what's going on there.

Reviewed By: john.brawn

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

Test was introduced in https://reviews.llvm.org/D126359

~~~

OS Laboratory. Huawei RRI. Saint-Petersburg

We'd lost some type test coverage in masked-intrinsic-cost-inseltpoison.ll

https://reviews.llvm.org/D131658 found a bug in
ReadPseudoRegisterValue which would mean we read out
of bounds if the s register number was high enough.

This adds a memory check to vpush-1-thumb, which
should have been doing that anyway. Then copies that
test and uses the last 4 s registers instead.

Without the mentioned fix we see random values in
the final memory, with the fix it passes.

Reviewed By: fixathon

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

[mlir][sparse] Refine f695554a wording a bit and fix the double conversion I broke with aggressive copy&paste

The patch uses peephole method to fold merge.vvm and unmasked intrinsics to
masked intrinsics. Using peephole intead of tablegen patterns is to avoid large
auto gnerated code.

Note: The patch ignores segment loads since I don't know how to test them.

Reviewed By: craig.topper

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

Follow-up after D131595, see comments in the review thread.

The intention of having two constructors was to minimize the copies of
`vector`, but a lack of `std::move` on the call site caused the wrong
constructor to be called.

Switched to a single constructor that accepts a value.
Accepting by value allows to have a single constructor and still decide
to copy or move on the call site.

Commit 8922adf6 recently made JITTargetMachineBuilder honor the
hasJIT property of the target. LLVM supports just-in-time compilation
on RISC-V, so set the flag.

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

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