Try to fix [issue](https://github.com/llvm/llvm-project/issues/73619

)

1. During transforming `FunctionProtoType`, if `ThisContext` is
`nullptr` and `CurrentContext` is `ClassTemplateSpecializationDecl`,
Constructor of `CXXThisScopeRAII` and `Sema::getCurrentThisType` won't
set `CXXThisTypeOverride` of Sema. This will lead to building `this` in
`RebuildCXXThisExpr` with a invalid type(NULL type) and cause crash.
2. During transforming attribute type, if `modifiedType` of attribute
type is changed, `EquivalentType` need to be transformed. If
`EquivalentType` is `FunctionProtoType`, its `ParamVarDecl` will not be
copyed(but parameter num does) and will not be instanced in
`TransformFunctionTypeParams` since `ParamVarDecl` is `nullptr`. This
will lead to crash in `findInstantiationOf`(can't find the instance of
`ParamVarDecl`).

This patch tries to fix these issues above.

1. If `CurrentContext` is `ClassTemplateSpecializationDecl`, Use it.
2. Use `EquivalentTypeLoc` instead of `EquivalentType` since it has
parameter info. But, if use current `TypeLocBuilder`, it will crash in
`TypeLocBuilder::push` since `LastType` is mismatch. Use an auxiliary
`TypeLocBuilder` instead and get transformed `EquivalentType`.

Co-authored-by: huqizhi <836744285@qq.com>

R16-R31 was added into GPRs in
https://github.com/llvm/llvm-project/pull/70958,
This patch supports the promoted ENQCMD, KEYLOCKER and USER-MSR
instructions in EVEX space.

RFC:
https://discourse.llvm.org/t/rfc-design-for-apx-feature-egpr-and-ndd-support/73031/4

Updating the value of the global flag within the code was flagged as a
TSAN error. Fixing that.

[mlir][TilingInterface] Use `LoopLikeOpInterface` in tiling using SCF to unify tiling with `scf.for` and `scf.forall`. (#77874)

Using `LoopLikeOpInterface` as the basis for the implementation unifies
all the tiling logic for both `scf.for` and `scf.forall`. The only
difference is the actual loop generation. This is a follow up to
https://github.com/llvm/llvm-project/pull/72178
Instead of many entry points for each loop type, the loop type is now
passed as part of the options passed to the tiling method.

This is a breaking change with the following changes

1) The `scf::tileUsingSCFForOp` is renamed to `scf::tileUsingSCF`
2) The `scf::tileUsingSCFForallOp` is deprecated. The same
   functionality is obtained by using `scf::tileUsingSCF` and setting
   the loop type in `scf::SCFTilingOptions` passed into this method to
   `scf::SCFTilingOptions::LoopType::ForallOp` (using the
   `setLoopType` method).
3) The `scf::tileConsumerAndFusedProducerGreedilyUsingSCFForOp` is
   renamed to `scf::tileConsumerAndFuseProducerUsingSCF`. The use of
   the `controlFn` in `scf::SCFTileAndFuseOptions` allows implementing
   any strategy with the default callback implemeting the greedy fusion.
4) The `scf::SCFTilingResult` and `scf::SCFTileAndFuseResult` now use
   `SmallVector<LoopLikeOpInterface>`.
5) To make `scf::ForallOp` implement the parts of
   `LoopLikeOpInterface` needed, the `getOutputBlockArguments()`
   method is replaced with `getRegionIterArgs()`

These changes now bring the tiling and fusion capabilities using
`scf.forall` on par with what was already supported by `scf.for`

Include LLVM_ENABLE_HTTPLIB along with httplib package finding in
LLVMConfig.cmake, as this dependency is needed by LLVMDebuginfod that is
now used by LLDB. Without it, building LLDB standalone fails with:

```
CMake Error at /usr/lib/llvm/19/lib64/cmake/llvm/LLVMExports.cmake:90 (set_target_properties):
  The link interface of target "LLVMDebuginfod" contains:

    httplib::httplib

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.

Call Stack (most recent call first):
  /usr/lib/llvm/19/lib64/cmake/llvm/LLVMConfig.cmake:357 (include)
  cmake/modules/LLDBStandalone.cmake:9 (find_package)
  CMakeLists.txt:34 (include)
```

Missing ending `` after c92ad411

This patch optimize:
  1. Reduce string size of RVVIntrinsicDef.
  2. Reduce the type size of the index of intrinsics.

I use valgrind --tool=massif to analyze a simple program:
```
#include <riscv_vector.h>
vint32m1_t test(vint32m1_t v1, vint32m1_t v2, size_t vl) {
  return __riscv_vadd(v1, v2, vl);
}
```
and before optimization, the peak memory usage is 15.68MB,
after optimization, the peak memory usage is 13.69MB.

This patch models LMUL and SEW as inputs in sf_vc_x_se and sf_vc_i_se,
it reduces 42 intrinsics in the lookup table.

It got lost in 50b58e89.

When we do not enable vector features, we should return the default
value (`TargetTransformInfoImplBase::getRegisterBitWidth`) instead of
zero.

This should fix the LoongArch [buildbot
breakage](https://lab.llvm.org/staging/#/builders/5/builds/486) from
#78943.

…ty in instrumentation code, be consistent with runtime

In runtime code, the size of memory block mapped to a single shadow
location is called MEM_GRANULARITY.
In instrumentation code, the size of memory block mapped to a single
shadow location is called DefaultShadowGranularity.
Actually, the SHADOW_GRANULARITY is 8 (1 << SHADOW_SCALE), and the
MEM_GRANULARITY is 64.
The wording of DefaultShadowGranularity in instrumentation code is a bit
misleading, this patch renames DefaultShadowGranularity to
DefaultMemGranularity, be consistent with runtime.

Moved from https://reviews.llvm.org/D126302

The current behaviour with these three options is quite undesirable:
-mno-altivec -mvsx allows VSX to override no Altivec, thereby turning on
both
-msoft-float -maltivec causes a crash if an actual Altivec instruction
is required because soft float turns of Altivec
-msoft-float -mvsx is also accepted with both Altivec and VSX turned off
(potentially causing crashes as above)

This patch diagnoses these impossible combinations in the driver so the
user does not end up with surprises in terms of their options being
ignored or silently overridden.

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



---------

Co-authored-by: Nemanja Ivanovic <nemanja.i.ibm@gmail.com>

There were buildbot failures when running memprof tests: 
Failed Tests (12):
  MemProfiler-x86_64-linux :: TestCases/interface_test.cpp
  MemProfiler-x86_64-linux :: TestCases/log_path_test.cpp
  MemProfiler-x86_64-linux :: TestCases/memprof_merge_mib.cpp
  MemProfiler-x86_64-linux :: TestCases/memprof_profile_dump.cpp
  MemProfiler-x86_64-linux :: TestCases/profile_reset.cpp
  MemProfiler-x86_64-linux :: TestCases/unaligned_loads_and_stores.cpp
  MemProfiler-x86_64-linux-dynamic :: TestCases/interface_test.cpp
  MemProfiler-x86_64-linux-dynamic :: TestCases/log_path_test.cpp
  MemProfiler-x86_64-linux-dynamic :: TestCases/memprof_merge_mib.cpp
  MemProfiler-x86_64-linux-dynamic :: TestCases/memprof_profile_dump.cpp
  MemProfiler-x86_64-linux-dynamic :: TestCases/profile_reset.cpp
MemProfiler-x86_64-linux-dynamic ::
TestCases/unaligned_loads_and_stores.cpp

See
- https://lab.llvm.org/buildbot/#/builders/258/builds/8852
- https://lab.llvm.org/buildbot/#/builders/258/builds/12876

I suspect the failure is because when build with
-DLLVM_ENABLE_RUNTIMES=compiler-rt -DCOMPILER_RT_BUILD_SANITIZERS=OFF,
the headers sanitizer/allocator_interface.h and
sanitizer/common_interface_defs.h
are not copied to the build tree, and not installed.
But in the failed memprof tests,
sanitizer/allocator_interface.h or sanitizer/memprof_interface.h is
included.

This patch adds sanitizer/allocator_interface.h and
sanitizer/memprof_interface.h to memprof headers if
COMPILER_RT_BUILD_SANITIZERS is false.

…e level.

Reverts llvm/llvm-project#79515

Some minor breakages. Will fix tomorrow.

This commit makes two variables static.
That makes two buildbot tests pass with short string annotations.
I suspect that there may be use after end of life bug and it's fixed by
this change, but it requires confirmation.

Short string annotations PR (reverted):
- https://github.com/llvm/llvm-project/pull/79049

Tests fixed with this PR:
```
  LLVM :: Transforms/Inline/cgscc-inline-replay.ll 
  LLVM :: Transforms/SampleProfile/inline-replay.ll
```
Buildbot output:
https://lab.llvm.org/buildbot/#/builders/5/builds/40364/steps/9/logs/stdio

This PR does not resolve a problem with `Clang :: SemaCXX/builtins.cpp`,
related PR is:
- https://github.com/llvm/llvm-project/pull/79522

The epoll_wait functions are syscall wrappers that were requested by
upstream users. This patch adds them, as well as their header and types.

The tests are currently incomplete since they require epoll_create to
properly test epoll_wait. That will be added in a followup patch since
this one is already very large.

The code that parses repeat counts, field widths, &c. from FORMAT
strings has an incorrect overflow check, so the maximum integer value is
not accepted. Fix.

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

…edures

Fortran allows a generic interface to have the same name as a derived
type in the same scope. It also allows a generic interface to have the
same name as one of its specific procedures.

When two modules define the same name, possibly more than once each,
things get exciting. The standard is not clear, and other compilers do
variously different things. We are currently emitting some errors
prematurely for some usage in pfUnit due to how it combines two versions
of a package together via USE association.

This patch handles combinations of derived types and generic interfaces
and their specific procedures in a more principled way. Errors due to
ambiguity are deferred to actual usage of derived types and specific
procedures -- and when they're not used, the program is unambiguous and
no error issues.

…ystems

flang/test/Preprocessing/pp133.F90 -> pp134.F90 to avoid pp133.f90.

These specific intrinsic functions are legacy names that map to the
standard generic NINT(..., KIND=8).

On macOS, the formatter is printing signed values as
unsigned, it seems, and the tests are expecting correctly
signed values.  These tests were added in
https://github.com/llvm/llvm-project/pull/78609

The runtime implements CONVERT="SWAP", but semantics doesn't like it.
Add it to the relevant table.

Fixes llvm-test-suite/Fortran/gfortran/regression/record_marker_1.f90,
.../unf_io_convert_1.f90, .../unf_io_convert_2.f90, and
.../unf_io_convert_3.f90.

We support specific intrinsic calls like `AMAX0(1.0,2)` that have
heterogeneous argument types as an optional extension in cases where the
specific intrinsic has a related generic intrinsic function capable of
handling the argument types. This feature can't be allowed to apply to
calls where the result of the related generic intrinsic function is not
convertible to the type of the specific intrinsic, as in `AMAX0('a',
'b')`.

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

CheckIPOSupported is used to test for working LTO since #74520. However, before CMake 3.24 this will test the default linker and ignore options such as LLVM_ENABLE_LLD. As a result, CMake would test whether LTO works with the default linker but builds with another one. In a typical scenario, libomptarget is compiled with the in-tree Clang, but linked with ld.gold, which requires the LLVMgold plugin, when it actually would work with the lld linker (or also fail because the system lld is too old to understand opaque pointers). Using gcc as the compiler would pass the test, but fail when linking with lld since does not understand gcc's LTO format.

Disable LTO by default for now since automatic detection causes too many problems. It causes the openmp-offload-cuda-project buildbot (https://lab.llvm.org/staging/#/builders/151) to fail and LLVM_ENABLE_RUNTIMES=openmp builds will have it implicitly disabled in the vast majority of syst...

https://github.com/llvm/llvm-project/issues/78927 contains a case of
fixed-form source in which a Hollerith literal is mistakenly tokenized,
leading to grief later due to apparently unbalanced parentheses.

The source looks like "REAL*8 R8HEAP(SCRSIZE)" and the Hollerith literal
is misrecognized as such because it follows "8R". In order to properly
tokenize Hollerith literals in old comma-free FORMAT statements like "1
FORMAT(3I5HFLANG)", the tokenizer in the prescanner treats a letter
after an integer token ("3I") as a special case. The fix is to do this
only when the characters involved are nested in parentheses and
Hollerith is a possibility.

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

Some Fortran codes use line continuation as a form of token pasting; see
https://github.com/llvm/llvm-project/issues/78797. This works in
compilers that run a C-like preprocessor and then apply line
continuation to its output; f18 implements line continuation during
tokenization and preprocessing, but can still handle this case.

In the rare case when an identifier is split across two or more
continuation lines, this patch allows its parts to be distinct
preprocessing tokens for the purpose of macro replacemnt. They (or their
replacement texts) can be effectively rejoined later as a single
identifier when the cooked character stream is tokenized in parsing.

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

The utility function GetRelevantObject() seems to be just wrong for
definability checks for the "base object" of a designator, and that's
all for which it is (now?) used. This leads to some false error messages
in Whizard when data-refs with multiple pointer components are defined.
Simplify, and add more test cases.

Encode BRANCHENTRY bits as bitmask for deduplicated entries.

Reduces BAT section size:
- large binary: to 11834216 bytes (0.31x original),
- medium binary: to 1565584 bytes (0.26x original),
- small binary: to 336 bytes (0.23x original).

Test Plan: Updated bolt/test/X86/bolt-address-translation.test

When an attribute specification statement follows a declaration that
applies the SAVE attribute to a symbol, name resolution can produce a
spurious error message about redundant SAVEs.

Fixes llvm-test-suite/Fortran/gfortran/regression/proc_ptr_9.f90.

In instcombine, when we sink an instruction into a successor block, we try
to clone and salvage all the variable assignments that use that Value. This
is a behaviour that's (IMO) flawed, but there are important use cases where
we want to avoid regressions, thus we're implementing this for the
non-instruction debug-info representation.

This patch refactors the dbg.value sinking code into it's own function, and
installs a parallel implementation for DPValues, the non-instruction
debug-info container. This is mostly identical to the dbg.value
implementation, except that we don't have an easy-to-access ordering
between DPValues, and have to jump through extra hoops to establish one in
the (rare) cases where that ordering is required.

The test added represents a common use-case in LLVM where these behaviours
are important: a loop has been completely optimised away, leaving several
dbg.values in a row referring to an instruction that's going to sink. The
dbg.values should sink in both dbg.value and RemoveDIs mode, and
additionally only the last assignment should sink.

The new accurate algorithm for real MOD and MODULO in the runtime is not
as fast as std::fmod(), which is also accurate. So use std::fmod() for
those floating-point types that it supports.

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

An || operator in namelist substring bounds checking really needs to be
an && operator so that the substring is viewed as correct only when both
its bounds are valid.

Fixes llvm-test-suite/Fortran/gfortran/regression/namelist_40.f90.

Cray pointees may not appear in COMMON blocks or EQUIVALENCE groups.

Fixes llvm-test-suite/Fortran/gfortran/regression/cray_pointers_4.f90.