D108961 introduced relaxation for out-of-range conditional branches.
However, relaxation was only performed when the branch target could be
resolved. I believe this has two undesired consequences:

- `b<cc> ... foo`, where `foo` is undefined, would not be relaxed
  although there is no guarantee the offset to `foo` will fit;
- Conditional branches are never relaxed with `-mattr=+relax` because MC
  considers fixups where `shouldForceRelocation` returns true (which
  will be the case with `+relax`) to be unresolved.

Note that binutils performs conditional branch relaxation in both cases.

This patch proposes to perform conditional branch relaxation even when
the target cannot be resolved.

Note on llvm/test/MC/RISCV/long-conditional-jump.s: I've removed the
`.p2align` because this causes alignment nops to be inserted for the
`+relax` tests. This in turn causes all the branch targets to change
compared to the non-`+relax` tests. Since `+relax` shouldn't change
these offsets, I found this confusing and hence chose to remove the
alignment.

Reviewed By: asb, MaskRay, reames

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

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

Implement XCVsimd intrinsics for CV32E40P according to the specification.

This commit is part of a patch-set to upstream the 7 vendor specific extensions of CV32E40P.

Contributors: @CharKeaney, @jeremybennett, @lewis-revill, @liaolucy, Nandni Jamnadas, @PaoloS, @simoncook, @xmj.

Reviewed By: craig.topper

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

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

D154958 enables branch relaxation for unresolved symbols. This has an
interesting consequence for some LLD tests: branch relocations are
tested by using branches to undefined symbols and defining them, with
different values, on the LLD command line. These tests broke and there
doesn't seem to be an easy workaround: as far as I can tell, there is no
way to convince llvm-mc to emit a branch relocation to an undefined
symbol without branch relaxation kicking in.

This patch proposes to add a flag, `-riscv-asm-relax-branches=0`, to do
just that. The main purpose for this flag is for testing but it might be
seen as a first step to some kind of "strict" or WYSIWYG mode (i.e.,
what you give to the assembler is exactly what comes out). The need for
this has been mentioned in, for example, D108961. However, I suspect
there will be a lot of discussion around what exactly such a strict mode
would look like. Therefore, I gated this feature behind a CLI flag
instead of adding a new target feature.

Reviewed By: asb, MaskRay

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

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

This ensures that llvm-symbolizer ignores them for symbolization.

Note: unlike aarch64-mapping-symbol.s, the test included here does not
test if the mapping symbols are actually in the symbol table. The reason
is that llvm-mc support for RISC-V mapping symbols (D153260) has not
landed yet, so the mapping symbols simply aren't there. However, D153260
would like to depend on this patch together with D156190 to avoid having
to update a large amount of tests.

Reviewed By: MaskRay

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

In preperation to move all remark utilities into one tool. We use
command registry to breakdown each utility into a separate file.

For now we have 3 utilities for remarks
1. Convert: which is responsible for converting yaml remarks to
   bitstream and vice-versa
2. Count: Analyse remarks and report count. This currently only supports
   asm-remarks and annotation-summary remarks.
3. Diff remarks: Currently we only have a diff for size remarks using
   `llvm-remark-size-diff`

The first two utilites have been simplified and seperated into two
files. The following commit will move `llvm-remark-size-diff` and fold
it to be inside `llvm-remarkutil` as a subcommand

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

Since __bf16 has been upgraded from a storage-only type to an arithmetic type in https://reviews.llvm.org/rGe62175736551abf40a3410bc246f58e650eb8158, it should support all the basic arithmetic operations like other float types, including increment and decrement.

Reviewed By: pengfei

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

This code is invalid, not unsupported.

This reverts commit 5a51a44f.

The build is broken.

According to the latest spec, Zvfbfwma requires Zvfbfmin and Zvfbfmin requires Zfbfmin, with FLH/FSH/FMV.H.X/HMV.X.H removed from Zvfbfwma.

Reviewed By: asb

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

This is more user-friendly over an opaque crash.

Reviewed By: lattner

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

Reviewed By: pengfei

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

Fix syntax issues in the reStructuredText file that prevented rendering them.

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

This reverts commit 885275bf.

llvm-objdump -d has been changed to not display mapping symbols by default.

Similar to D96617 for llvm-symbolizer.

This patch matches the GNU objdump -d behavior to suppress printing
labels for mapping symbols. Mapping symbol names don't convey much
information.

When --show-all-symbols (not in GNU) is specified, we still print
mapping symbols.

Note: the `for (size_t SI = 0, SE = Symbols.size(); SI != SE;)` loops
needs to iterate all mapping symbols, even if they are not displayed.
We use the new field `IsMappingSymbol` to recognize mapping symbols.
This field also enables simplification after D139131.

ELF/ARM/disassemble-all-mapping-symbols.s is enhanced to add `.space 2`.
If `End = std::min(End, Symbols[SI].Addr);` is not correctly set, we
would print a `.word`.

Reviewed By: jhenderson, jobnoorman, peter.smith

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

These tests only use yaml2obj and llvm-nm, which do not need
LLVM_TARGETS_TO_BUILD.

and omit them from llvm-nm output unless --special-syms is specified,
similar to ARM and AArch64.

This is a prerequisite of D156190 as llvm-objdump will only perform
mapping symbol recognition for SF_FormatSpecific symbols.

Implement XCValu intrinsics for CV32E40P according to the specification.

This is a commit of the patch-set to upstream the 7 vendor specific extensions of CV32E40P.

Contributors: @CharKeaney, Nandni Jamnadas, Serkan Muhcu, @jeremybennett, @lewis-revill, @liaolucy, @simoncook, @xmj

Reviewed By: craig.topper

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

https://reviews.llvm.org/D144252 removed -Wno-unused-function from the
libunwind build, but we have an unused function when you're building for
armv7 without assertions. Mark that function as possibly unused to avoid
the warning, and mark the parameter as a const pointer while I'm here to
make it clear that nothing is modified by a debugging function.

Reviewed By: #libunwind, philnik

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

to prevent overload resolution confusion. In particular, if we add
another parameter to the generic constructor, MCDisassemblerTest.cpp
specified constructors will be resolve to the generic constructor, which
is unintended.

llvm-objdump -d will be changed to not display mapping symbols by
default (D156190).
Add --show-all-symbols to make the intent clearer and prevent test
adjustment with the new behavior.

This patch adds codegen support for vector with bfloat16 type in llvm backend.
With this patch, Zvbfmin/Zvbfwma instructions as well as vle16/vse16 can generated from newly added bf16 IR intrinsics.

Reviewed By: craig.topper

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

This allows for users of the lsp transport libraries to process replies
in parallel, without overlapping/clobbering the output.

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

Api available since Windows Server 2016/Windows 10 1607

Reviewed By: vitalybuka

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

These test cases are checking specific functions in call stacks.
But if the call stack order is changed (e.g. another function is not inlined),
the frame number would be different.
This patch loose the frame number checks for those conditions.

Depends on D139827

Reviewed By: vitalybuka

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

I actually visited each link and added relevant context directly to the code.

This is related to the effort to eliminate internal bug tracker links
(d618f1c3, e0ac46e6).

Test files still have a lot of rdar links and ids in them.
I haven't touched them yet.

If JITLinkGeneric::linkPhase2 receives an Error rather than an InFlightAlloc
then we need to call JITLinkContext::notifyFailed, rather than calling
abandonAllocAndBailOut -- the latter asserts that there is an allocation to
abandon, and this was turning allocation errors into assertion failures in
debug mode.

The code was written with the implicit assumption that each IMPLICIT_DEF either a) the tied operand, or b) an untied source, but not both. This is true right now, but an upcoming change may allow CSE of IMPLICIT_DEFs in some cases, so let's rewrite the code to handle that possibility.

I added an MIR case which demonstrates the multiple use IMPLICIT_DEF. To my knowledge, this is not a reachable configuration from IR right now.

As an aside, this makes the structure a much closer match with the sub-reg liveness case, and we can probably just merge these routines. (Future work.)

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

insertelement instructions.

If the original vector has undef, not poison values, which are not
rewritten by later insertelement instructions, need to transform shuffle
with the undef vector, not a poison vector, and actual indices, not
PoisonMaskElem, otherwise the transformation may produce more poisons
output than the input.

[llvm-profdata] Refactoring Sample Profile Reader to increase FDO build speed using MD5 as key to Sample Profile map

This is phase 1 of multiple planned improvements on the sample profile loader.   The major change is to use MD5 hash code ((instead of the function itself) as the key to look up the function offset table and the profiles, which significantly reduce the time it takes to construct the map.

The optimization is based on the fact that many practical sample profiles are using MD5 values for function names to reduce profile size, so we shouldn't need to convert the MD5 to a string and then to a SampleContext and use it as the map's key, because it's extremely slow.

Several changes to note:

(1) For non-CS SampleContext, if it is already MD5 string, the hash value will be its integral value, instead of hashing the MD5 again. In phase 2 this is going to be optimized further using a union to represent MD5 function (without converting it to string) and regular function names.

(2) The SampleProfileMap is a wrapper to *map<uint64_t, FunctionSamples>, while providing interface allowing using SampleContext as key, so that existing code still work. It will check for MD5 collision (unlikely but not too unlikely, since we only takes the lower 64 bits) and handle it to at least guarantee compilation correctness (conflicting old profile is dropped, instead of returning an old profile with inconsistent context). Other code should not try to use MD5 as key to access the map directly, because it will not be able to handle MD5 collision at all. (see exception at (5) )

(3) Any SampleProfileMap::emplace() followed by SampleContext assignment if newly inserted, should be replaced with SampleProfileMap::Create(), which does the same thing.

(4) Previously we ensure an invariant that in SampleProfileMap, the key is equal to the Context of the value, for profile map that is eventually being used for output (as in llvm-profdata/llvm-profgen). Since the key became MD5 hash, only the value keeps the context now, in several places where an intermediate SampleProfileMap is created, each new FunctionSample's context is set immediately after insertion, which is necessary to "remember" the context otherwise irretrievable.

(5) When reading a profile, we cache the MD5 values of all functions, because they are used at least twice (one to index into FuncOffsetTable, the other into SampleProfileMap, more if there are additional sections), in this case the SampleProfileMap is directly accessed with MD5 value so that we don't recalculate it each time (expensive)

Performance impact:
When reading a ~1GB extbinary profile (fixed length MD5, not compressed) with 10 million function names and 2.5 million top level functions (non CS functions, each function has varying nesting level from 0 to 20), this patch improves the function offset table loading time by 20%, and improves full profile read by 5%.

Reviewed By: davidxl, snehasish

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

The example describing bitcasts (and memory layout) involving
vector types was incorrect for little endian.

This was reported in https://reviews.llvm.org/D94964