This reverts commit 0c41eea4.

Without this patch, a lot of details about the deserilization of the
MemProf data are exposed in IndexedInstrProfReader -- four
MemProf-related variables in IndexedInstrProfReader plus 90+ lines of
deserilization code within IndexedInstrProfReader::readHeader.

This patch encapsulates them into a separate class, exposing only
three methods, namely the default constructor, deserialize, and
getMemProfRecord.

This patch fixes

  clang/lib/Sema/SemaStmtAttr.cpp:114:18: error: unused variable 'R'
  [-Werror,-Wunused-variable]

Since `vcreate` doesn't support overload, we can remove it.

[Clang] Allow the value of unroll count to be zero  in `#pragma GCC unroll` and `#pragma unroll` (#88666)

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

GCC allows the value of loop unroll count to be zero, and the values of
0 and 1 block any unrolling of the loop. This PR aims to make clang
keeps the same behavior with GCC.
https://gcc.gnu.org/onlinedocs/gcc/Loop-Specific-Pragmas.html



---------

Signed-off-by: yronglin <yronglin777@gmail.com>

If LLVM is configured with -DLLVM_DEFAULT_TARGET_TRIPLE, or compiler_rt
is configured with -DCOMPILER_RT_DEFAULT_TARGET_TRIPLE, while the
argument is not normalized, such as Debian-style vendor-less triple,
clang will try to find libclang_rt in lib/<normalized_triple>, while
libclang_rt is placed into lib/<triple_arg>.

Let's also place libclang_rt into lib/<normalized_triple>.
`libcxx/utils/ci/run-buildbot` is also updated to use
`armv7m-none-unknown-eabi` as normalized triple instead of
current `armv7m-none-eabi`.

ChangeLog of this PR:
This patch has been applied and revert twice:
1. The first try is https://github.com/llvm/llvm-project/pull/88407, and
then it is found that it causes some CI failures.
    https://lab.llvm.org/buildbot/#/builders/98/builds/36366
It is then resolved by another commit:
https://github.com/llvm/llvm-project/commit/1693009679313282afbed38778dd3fad62641e1b

    https://lab.llvm.org/buildbot/#/builders/77/builds/36372
It is caused that `COMPILER_RT_DEFAULT_TARGET_TRIPLE` is overwrite
without taking care about `CACHE`.

2. The second try https://github.com/llvm/llvm-project/pull/88835,
     resolves https://lab.llvm.org/buildbot/#/builders/77/builds/36372
     and in fact only one `execute_process` is needed.

Then we find some other CI failures. 
https://github.com/mstorsjo/llvm-mingw/actions/runs/8730621159

https://buildkite.com/llvm-project/libcxx-ci/builds/34897#018eec06-612c-47f1-9931-d3bd88bf7ced

It is due to misunderstanding `-print-effective-triple`: which will
output `thumbv7-w64-windows-gnu` for `armv7-w64-windows-gnu` or some
other thumb-enabled arm triples.
In fact we should use `-print-target-triple`.

For armv7m-picolibc, `armv7m-none-eabi` is hardcoded in
libcxx/utils/ci/run-buildbot, while in fact `armv7m-none-unknown-eabi`
is the real normalized triple.

APX spec: https://cdrdv2.intel.com/v1/dl/getContent/784266
Change happended in version 4.0.
Removed instructions' Opcodes:
AESDEC128KL
AESDEC256KL
AESDECWIDE128KL
AESDECWIDE256KL
AESENC128KL
AESENC256KL
AESENCWIDE128KL
AESENCWIDE256KL
ENCODEKEY128
ENCODEKEY256
SHA1MSG1
SHA1MSG2
SHA1NEXTE
SHA1RNDS4
SHA256MSG1
SHA256MSG2
SHA256RNDS2

InstCombine may invert branch condition and profile metadata. Branch
probability analysis should be updated in this case.

Close https://github.com/llvm/llvm-project/issues/85122

As the title suggested, it looks pretty sensible.

This allows vector splats containing poison for matchers using
api_pred_ty, making the behavior consistent with cst_pred_ty. In other
words, previously `m_NonNegative()` allowed splats with poison, while
`m_NonNegative(C)` did not. Now both allow them.

The affected matchers are m_MaxSignedValue, m_Negative, m_NonNegative,
m_StrictlyPositive, m_NonPositive, m_Power2, m_Power2OrZero,
m_NegatedPower2, m_NegatedPower2OrZero, m_LowBitMask and
m_LowBitMaskOrZero when passing in APInt.

I briefly went through the uses of these matchers and didn't spot any
places where allowing poison would be obviously wrong (I initially
thought foldSelectICmpAndBinOp is problematic, but because it does not
reuse the original constants, it's fine).

A problem here is that, despite these matchers appearing in a decent
number of places, we have very little pre-existing test coverage for
these folds with poison vectors, so we don't benefit from alive2
verification.

Only unique `OpaqueValueExpr`s should be handled in the mapping builder,
as
[discussed](https://github.com/llvm/llvm-project/pull/85837#discussion_r1542056451)
in #85837. However, `getCond()` returns non-unique `OpaqueValueExpr` for
`BinaryConditionalOperator` (because it is also used as the "true"
branch expression). Use `getCommon()` instead so as to bypass the
`OpaqueValueExpr`.

This adds proper support for calling intrinsics without mangling suffix
when parsing textual IR. This already worked (mostly by accident) when
only a single mangling suffix was in use.

This patch extends support to the case where the intrinsic is used with
multiple signatures, and as such multiple different intrinsic
declarations have to be inserted. The final IR will have intrinsics with
mangling suffix as usual.

Motivated by the discussion at:
https://discourse.llvm.org/t/recent-improvements-to-the-ir-parser/77366

Now that we don't accept undef splat in PatternMatch, we can remove some
uses of replaceUndefsWith(). I believe in all these cases only poison
splats are possible now, in which case no replacement is necessary.

Tested locally against msvc 1939.
MSVC supports the colon form of various options that take a path even
though that isn't documented for all options on MSDN.
I added the colon form for all supported msvc options that clang-cl does
not intentionally ignore due to being unsupported.

I also fixed the existing colon options by ensure we use
`JoinedOrSeparate`. `/F[x]` argument must used within the same command
line argument. However, `/F[x]:` arguments are allowed to span a command
line argument. The following is valid `/F[x]: path` which is 2 separate
command line arguments.
You can see this documented here,
https://learn.microsoft.com/en-us/cpp/build/reference/fo-object-file-name?view=msvc-170,
where it says `/Fo:[ ]"pathname"`.
This behaviour works for all colon options that take a path and I tested
it locally against msvc 1939 for all the option changes in this PR.

In the recent fenv.h header cleanup, two FEnvImpl.h files were missed,
causing build issues. This patch fixes that.

The couple other places that use the oso module's SymbolFile, they check
that it's non-null, so this is just an oversight in
ResolveSymbolContext.

I didn't add a test for this (but did add a log message for the error
case) because I can't see how this would actually happen. The .o file
had to have valid enough DWARF that the linker's parser could handle it
or it would not be in the debug map. If you delete the .o file, we just
leave that entry out of the debug map. If you strip it or otherwise mess
with it, we'll notice the changed mod time and refuse to read it...

This was based on a report from the field, and we don't have access to
the project. But if the logging tells me how this happened I can come
back and add a test with that example.

The test case is based on hwasan-check-memaccess.ll (albeit updated
using update_llc_test_checks) with --hwasan-mapping-offset=...

--hwasan-mapping-offset=... actually doesn't affect the LLVM IR at the
moment; future work will introduce memaccess fixed shadow intrinsics.
(https://github.com/llvm/llvm-project/pull/89319)

These are needed to populate elf headers in core files. This is part of
implementing process save-core in lldb

This is needed now that this depends on it:
ee0284ec



Co-authored-by: Will Dietz <w@wdtz.org>

This member variable is completely unused. I also don't think it makes a
ton of sense since (1) The "base address" can be obtained from the first
Instruction in its InstructionList, and (2) InstructionLists may not be
a series of contiguous instructions (even though they are most of the
time).

This PR changes the LLVM dialect's IntegerOverflowFlags to be stored on
operations as native properties.

This is useful for defining operation properties that are enums.

PR link: https://github.com/llvm/llvm-project/pull/84694

This change is in line with similar notation in SPIRV. 

Decoupling version numbering of DXIL and of Shader Model is intended to
enable accurate specification of DXIL features that can be targeted by
different Shader Model versions.

This is partly for readability and partly for consistency with other
id-to-frame callbacks.

`clang -g -gpubnames` (with optional -gsplit-dwarf) creates the
`.debug_names` section ("per-CU" index). By default lld concatenates
input `.debug_names` sections into an output `.debug_names` section.
LLDB can consume the concatenated section but the lookup performance is
not good.

This patch adds --debug-names to create a per-module index by combining
the per-CU indexes into a single index that covers the entire load
module. The produced `.debug_names` is a replacement for `.gdb_index`.

Type units (-fdebug-types-section) are not handled yet.

Co-authored-by: Fangrui Song <i@maskray.me>

---------

Co-authored-by: Fangrui Song <i@maskray.me>

This patch adds Version2 of the indexed MemProf format.  The new
format comes with a hash table from CallStackId to actual call stacks
llvm::SmallVector<FrameId>.  The rest of the format refers to call
stacks with CallStackId.  This "values + references" model effectively
deduplicates call stacks.  Without this patch, a large indexed memprof
file of mine shrinks from 4.4GB to 1.6GB, a 64% reduction.

This patch does not make Version2 generally available yet as I am
planning to make a few more changes to the format.

Tagging bugs as "good first issue" and taking the time to work with new
contributors pays dividends.

The memory sanitizer doesn't recognize the results of the pipe syscall
as being initialized. This patch manually unpoisons that memory.

The 'vector_length' clause is semantically identical to the
'num_workers' clause, in that it takes a mandatory single int-expr. This
is implemented identically to it.

Moving towards displaying impl status of standard header macros. The macros
aren't handled by docgen yet, so I haven't included updated rst files.

Fix issue https://github.com/llvm/llvm-project/issues/54624

Add front end flags -gtemplate-alias (also a cc1 flag) and -gno-template-alias
to enable/disable usage of the feature. It's enabled by default in the front
end for SCE debugger tuning only.

GCC emits DW_TAG_typedef for template aliases (as does Clang with this feature
disabled), and GDB and LLDB appear not to support DW_TAG_template_alias.

The -Xclang option -gsimple-template-names=mangled is treated the same as
=full, which is not a regression from current behaviour for template
aliases.

The current implementation omits defaulted arguments and as a consequence
also omits empty parameter packs that come after defaulted arguments. Again,
this isn't a regression as the DW_TAG_typedef name doesn't contain defaulted
arguments.

LLVM support added in https://github.com/llvm/llvm-project/pull/88943

Added template-alias.cpp - Check the metadata construction & interaction with
      -gsimple-template-names.
Added variadic-template-alias.cpp - Check template parameter packs work.
Added defaulted-template-alias.cpp - Check defaulted args (don't) work.
Modified debug-options.c - Check Clang generates correct cc1 flags.

This clause just takes an 'int expr', which is not optional. This patch
implements the clause on compute constructs.