This reverts commit 68b863b7.
088aa81a was reverted in efce8a05.

This reverts commit 088aa81a.

Setting the correct build flags on z/OS to build LLVM as 64-bit ASCII
application.

If we want to turn this on on some platforms, we'll also want to
define HAS_LOGF128 for AnalysisTest, see
llvm/unittests/Analysis/CMakeLists.txt

Fixes #84732, #81947, #81946

Note: This is a fix till we enable delayed privatization.

This is a second attempt to land #84501 which failed on several targets.

This patch adds the HAS_IEE754_FLOAT128 define which makes the check for
typedef'ing float128 more precise by checking whether __uint128_t is available
and checking if the host does not use __ibm128 which is prevalent on power pc
targets and replaces IEEE754 float128s.

Update the wrappers for the C std headers so that they always forward to
the z/OS system headers.

Improved detection of const/splat candidates, their matching and analysis of instructions from same nodes.

Metric: size..text

Program                                                                                                                                                size..text
                                                                                                                                                       results     results0    diff
                                                                                                                                                       results     results0    diff
                                                                             test-suite :: MultiSource/Benchmarks/DOE-ProxyApps-C++/miniFE/miniFE.test    92952.00    93096.00  0.2%
                                                                                     test-suite :: External/SPEC/CINT2006/464.h264ref/464.h264ref.test   779832.00   780136.00  0.0%
                                                                                          test-suite :: MultiSource/Applications/JM/lencod/lencod.test   839923.00   840179.00  0.0%
                                                                                          test-suite :: MultiSource/Applications/JM/ldecod/ldecod.test   392708.00   392740.00  0.0%
                                                                                test-suite :: External/SPEC/CFP2017rate/511.povray_r/511.povray_r.test  1171131.00  1171147.00  0.0%

                                                                              test-suite :: External/SPEC/CFP2017rate/538.imagick_r/538.imagick_r.test  1391089.00  1391073.00 -0.0%
                                                                             test-suite :: External/SPEC/CFP2017speed/638.imagick_s/638.imagick_s.test  1391089.00  1391073.00 -0.0%
                                                                              test-suite :: External/SPEC/CFP2017rate/526.blender_r/526.blender_r.test 12352780.00 12352636.00 -0.0%

MultiSource/Benchmarks/DOE-ProxyApps-C++/miniFE/miniFE - small
reordering
External/SPEC/CINT2006/464.h264ref/464.h264ref - small better code after
reordering
MultiSource/Applications/JM/lencod/lencod - smaller code with less
shuffles
MultiSource/Applications/JM/ldecod/ldecod - same
External/SPEC/CFP2017rate/511.povray_r/511.povray_r - 2 extra loads
vectorized, smaller code
External/SPEC/CFP2017rate/538.imagick_r/538.imagick_r - better code,
size increased because of more constant vectors.
External/SPEC/CFP2017speed/638.imagick_s/638.imagick_s - same
External/SPEC/CFP2017rate/526.blender_r/526.blender_r - small change in
the vectorized code, some code a bit better, some a bit worse.

Reviewers: RKSimon

Reviewed By: RKSimon

Pull Request: https://github.com/llvm/llvm-project/pull/87091

Adds transformation of consecutive vector store + reverse to strided
stores with stride -1, if it is profitable

Reviewers: RKSimon, preames

Reviewed By: RKSimon

Pull Request: https://github.com/llvm/llvm-project/pull/90464

582c6a82 removed a constructor of
'ResourceSegments' that is needed in LLVM unit tests.

* Revert 582c6a82
* Update the constructor to take a const reference of
  `std::list` as pointed out in #89193.

The intent is to test lowering of vector operations by scalarization,
for functions that are streaming-compatible (and thus cannot use NEON)
and also don't have the +sve attribute.

The generated code is clearly wrong at the moment, but a series of
patches will follow to fix up all cases to use scalar instructions.

A bit of context:

This work will form the base to decouple SME from SVE later on, as it
will make sure that no NEON instructions are used in
streaming[-compatible] mode. Later this will be followed by a patch that
changes `useSVEForFixedLengthVectors` to only return `true` if SVE is
available for the given runtime mode, at which point I'll change the
`-mattr=+sme -force-streaming-compatible-sve` to `-mattr=+sme
-force-streaming-sve` in the RUN lines, so that the tests are considered
to be executed in Streaming-SVE mode.

https://github.com/llvm/llvm-project/pull/90201 made some fixes for
gfx12
image_msaa_load waitcnt insertion.
That fix might break in some situations for pre-gfx12 - this fixes that
by
explitly checking for VSAMPLE which always requires a s_wait_samplecnt
and
leaves the previous logic intact for non-gfx12.

Code to determine if a waitcnt is required before a barrier instruction
only
considered S_BARRIER.
gfx12 adds barrier_signal/wait so need to enhance the existing code to
look for
a barrier start (which is just an S_BARRIER for earlier architectures).

Closes #89193

The autogenerated memory legalizer tests use -O0 so this allows us to
see the exact waitcnts that were inserted by the memory legalizer
without them being optimized away.

We are effectively performing type and operation legalisation very early
within the code generation flow. This results in worse code quality
because the DAG is not in canonical form, which DAGCombiner corrects
through the introduction of operations that are not legal.

This patchs splits and moves the code to where type and operation
legalisation is typically implemented.

Part of <https://github.com/llvm/llvm-project/issues/62629>.

* Replace "we" with either "you" (when talking to the reader) or "lldb"
(when talking about the project).
* Refer to lldb as lldb not LLDB, to match what the user sees on
the command line (I am going to come back later and put the proper name in places where it's talking about the projects themselves)
* Remove a bunch of contractions for example "won't". Which don't (pun
intended) seem like a big deal at first but even I as a native English
speaker find the text clearer with them expanded.
* Use RST's plain text highlighting for keywords and command names.
* Split some very long lines for easier editing in future.

Fixes #89544

Previously ObjectLinkingLayer held unique ownership of Plugins, and links
always used the Layer's plugin list at each step. This can cause problems if
plugins are added while links are in progress however, as the newly added
plugin may receive only some of the callbacks for links that are already
running.

In this patch each link gets its own copy of the pipeline that remains
consistent throughout the link's lifetime, and it is guaranteed that Plugin
objects (now with shared ownership) will remain valid until the link completes.

Coding my way home: 9.80469S, 139.03167W

There were two diffs that introduced some options useful when you build
modules externally and cannot rely on file modification time as the key
for detecting input file changes:
- [D67249](https://reviews.llvm.org/D67249) introduced the
`-fmodules-validate-input-files-content` option, which allows the use of
file content hash in addition to the modification time.
- [D141632](https://reviews.llvm.org/D141632) propagated the use of
`-fno-pch-timestamps` with Clang modules.

There is a problem when the size of the input file (header) is not
modified but the content is. In this case, Clang cannot detect the file
change when the `-fno-pch-timestamps` option is used. The
`-fmodules-validate-input-files-content` option should help, but there
is an issue with its application: it's not applied when the modification
time is stored as zero that is the case for `-fno-pch-timestamps`.

The issue can be fixed using the same trick that was applied during the
processing of `ForceCheckCXX20ModulesInputFiles`:
```
  // When ForceCheckCXX20ModulesInputFiles and ValidateASTInputFilesContent
  // enabled, it is better to check the contents of the inputs. Since we can't
  // get correct modified time information for inputs from overriden inputs.
  if (HSOpts.ForceCheckCXX20ModulesInputFiles && ValidateASTInputFilesContent &&
      F.StandardCXXModule && FileChange.Kind == Change::None)
    FileChange = HasInputContentChanged(FileChange);
```
The patch suggests the solution similar to the presented above and
includes a LIT test to verify it.

For the platform and extension doc.

Also add links in the extension doc to the GDB specs we're extending.

This patch fix the crash reported in:
https://github.com/llvm/llvm-project/issues/90589

This takes the form of three consecutive but related changes:
- Mark the fast path of BumpPtrAllocator as likely-taken.
- Move the slow path of BumpPtrAllocator to a separate function.
- Mark the slow path of BumpPtrAllocator as noinline.

Overall, this saves geomean 0.4% userspace instructions on CTMark -O3,
and 0.98% on CTMark -O0 -g.


http://llvm-compile-time-tracker.com/compare.php?from=e1622e189e8c0ef457bfac528f90a7a930d9aad2&to=9eb53a4ed3af4a55e769ae1dd22d034b63d046e3&stat=instructions%3Au

This matches what comes out of isel since
a63bd7e9. It also adds the undef flag to
more closely match the output after regalloc, which will help with the test
diffs in #70549

Canonicalize getelementptr instructions for scalable vector types into
ptradd representation with an explicit llvm.vscale call. This
representation has better support in BasicAA, which can reason about
llvm.vscale, but not plain scalable GEPs.

Reverts llvm/llvm-project#90180

See `llvm/unittests/IR/BasicBlockDbgInfoTest.cpp` for a test case.

Follow up to #90310, limit the tune up only to ThinLTO pre-link as
coroutine passes are not in MonoLTO backend

When delayed privatization is enabled, this PR emits the deallocation
logic to the newly introduced `dealloc` region on `omp.private` ops.

A pack indexing type can appear in a larger pack expansion, e.g
`Pack...[pack_of_indexes]...` so we need to temporarily disable
substitution of pack elements.

Besides, this patch also fixes an assertion failure in
`PackIndexingExpr::classify`: dependent `PackIndexingExpr`s are always
LValues and thus we don't need to consider their `IndexExpr`s.

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



---------

Co-authored-by: cor3ntin <corentinjabot@gmail.com>

Reverts llvm/llvm-project#90679

Fixes #60040.

This patch updates the compatibility checks for CUDA attribute iin
preparation to implement the matching rules described in section 3.2.3.
We this patch the compiler will still emit an error when there is
multiple specific procedures that matches since the matching distances
is not yet implemented. This will be done in a separate patch.


https://docs.nvidia.com/hpc-sdk/archive/24.3/compilers/cuda-fortran-prog-guide/index.html#cfref-var-attr-unified-data

gpu=unified and gpu=managed are not part of this patch since these
options are not recognized by flang yet.

LoadLibraryW will lookup dlls in user directories if its search path is
left unrestricted. This is a security vulnerability as one can name a
shared library the same as that of a system dll in order to run
arbitrary code when the shared library is loaded from the path in a user
directory. This change modifies it to only search within sys32 when
loading dbghelp.dll.