**Context:**
- In https://lists.llvm.org/pipermail/llvm-dev/2016-June/101804.html and commit 07670b3e984db32f291373fe12c392959f2aff67, `cl::SubCommand` is introduced.
- Options that don't specify subcommand goes into a special 'top level' subcommand.
**Motivating Use Case:**
- The motivating use case is to refactor `llvm-profdata` to use `cl::SubCommand` to organize subcommands. See
https://github.com/llvm/llvm-project/pull/71328. A valid use case that's not supported before this patch is shown below
```
// show-option{1,2} are associated with 'show' subcommand.
// top-level-option3 is in top-level subcomand (e.g., `profile-isfs` in SampleProfReader.cpp)
llvm-profdata show --show-option1 --show-option2 --top-level-option3
```
- Before this patch, option handler look-up will fail with the following error message "Unknown command line argument --top-level-option3".
- After this patch, option handler look-up will look up in sub-command options first, and use top-level subcommand as a fallback, so 'top-level-option3' is parsed correctly.
Long scalar values can be split into multiple lines to improve
readability. The rules are described in Section 6.5. "Line Folding",
https://yaml.org/spec/1.2.2/#65-line-folding. In addition, for flow
scalar styles, the Spec states that "All leading and trailing white
space characters on each line are excluded from the content",
https://yaml.org/spec/1.2.2/#73-flow-scalar-styles.
The patch implements these unfolding rules for double-quoted,
single-quoted, and plain scalars.
On windows if you passed /lldltocache:D:\tmp to lld and you didn't have
D: mounted it fail to create the cache dir D:\tmp, but the error message
is pretty hard to understand:
```
c:\code\llvm\llvm-project\out\debug>bin\lld-link.exe /lldltocache:D:\tmp
hello.obj
LLVM ERROR: no such file or directory
PLEASE submit a bug report to
https://github.com/llvm/llvm-project/issues/ and include the crash
backtrace.
Exception Code: 0xC000001D
```
Which lead one of our users to report this as a crash. I have just added
a bit better message so it now says:
```
c:\code\llvm\llvm-project\out\debug>bin\lld-link.exe /lldltocache:D:\tmp
hello.obj
LLVM ERROR: Can't create cache directory: D:\tmp
PLEASE submit a bug report to
https://github.com/llvm/llvm-project/issues/ and include the crash
backtrace.
```
I am not sure this is a fatal error because it's not something that
really should be reported as a bug to LLVM. But at least this gives a
bit more visibility on what to change.
As the comments of `InvalidateInstructionCache`: Before the JIT can run
a block of code that has been emitted it must invalidate the instruction
cache on some platforms. I think it applies to LoongArch as LoongArch
has a weak memory-model. But I'm not able to write a test to demonstrate
this issue. Perhaps self-modifing code should be wrote?
The `YAMLParser.h` header file claims support for YAML 1.2 with a few
deviations, but our plain scalar parsing failed to parse some valid YAML
according to the spec. This change puts us more in compliance with the
YAML spec, now letting us parse plain scalars containing additional
special characters in cases where they are not ambiguous.
When the input document is non-empty, `mapOptional` works as expected,
setting `std::optional` to `std::nullopt` when the field is not present.
When the input document is empty, we hit a special case inside of
`Input::preflightKey` that results in `UseDefault = false`, which
results in the `std::optional` erroneously being set to a non-nullopt
value. `preflightKey` is changed to set `UseDefault = true` in this case
to make the behavior consistent between empty and non-empty documents.
Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class as opposed to an
enum. This patch replaces support::{big,little,native} with
llvm::endianness::{big,little,native}.
The existing format of backreferences, `\<ref>`, does not allow digits
to be placed directly after the reference because they are included in
the reference number. The new format solves this problem by adding
explicit delimiters.
Now that llvm::support::endianness has been renamed to
llvm::endianness, we can use the shorter form. This patch replaces
support::endianness with llvm::endianness.
Now that llvm::support::endianness has been renamed to
llvm::endianness, we can use the shorter form. This patch replaces
llvm::support::endianness with llvm::endianness.
Now that llvm::support::endianness has been renamed to
llvm::endianness, we can directly get endianness from the llvm
namespace. We don't need to go through support.
This adds support for generating Chrome-tracing .json profile traces in
the LLD COFF driver.
Also add the necessary time scopes, so that the profile trace shows in
great detail which tasks are executed.
As an example, this is what we see when linking a Unreal Engine
executable:
Following the version bump in #67964 and the bug fix in #68026 I believe
we're ready to mark Zfa as non-experimental. I'll note the GCC torture
suite passes now with Zfa enabled (though it's more of a litmus test
than anything else).
The Zfa specification was recently ratified
<https://wiki.riscv.org/display/HOME/Recently+Ratified+Extensions>. This
commit bumps the version to 1.0, but leaves it as an experimental
extension (to be done in a follow-on patch), so reviews can focus on
confirming there haven't been spec changes we have missed (which as
noted below, is more difficult than usual).
Because the development of the Zfa spec overlapped with the transition
of riscv-isa-manual from LaTeX to AsciiDoc, it's more difficult than
usual to confirm version changes. The linked PDF in RISCVUsage is for
some reason a 404. Key commit histories to review are:
* Changes to zfa.adoc on the main branch
<https://github.com/riscv/riscv-isa-manual/commits/main/src/zfa.adoc>
* Changes to zfa.tex on the now defunct latex branch
<https://github.com/riscv/riscv-isa-manual/commits/latex/src/zfa.tex>
From reviewing these, I believe there have been no changes to the spec
since version 0.1/0.2 (sadly the AsciiDoc and LaTeX versions of the spec
are inconsistent about version numbering).
The threading library does not recognize AIX and always returns `-1` for
number of physical cores on AIX. This PR teaches the library to
recognize AIX and obtain the correct value for the number of physical
cores.
Multiplying raw block frequency with an integer carries a high risk
of overflow.
- Add `BlockFrequency::mul` return an std::optional with the product
or `nullopt` to indicate an overflow.
- Fix two instances where overflow was likely.
Add const qualifier to avoid warning "_cast from 'const char *' to 'char*' drops const qualifier [-Werror,-Wcast-qual]_"
This will allow enable LLVM_ENABLE_WERROR when build with clang-cl on Windows.
This is imported from https://github.com/openbsd/src/commit/b81763002452802e4f7304ea60f121253bd94
Also removed the gcc change for the cast-qual warning which is not needed with const qualifier added.
The FileIndex values returned from GetFileInformationByHandle are
considered stable and uniquely identifying a file, as long as the
handle is open. When handles are closed, there are no guarantees
for their stability or uniqueness. On some file systems (such as
NTFS), the indices are documented to be stable even across handles.
But with some file systems, in particular network mounts, file
indices can be reused very soon after handles are closed.
When such file indices are used for LLVM's UniqueID, files are
considered duplicates as soon as the filesystem driver happens to
have used the same file index for the handle used to inspect the
file. This caused widespread, non-obvious (seemingly random)
breakage. This can happen e.g. if running on a directory that is
shared via Remote Desktop or VirtualBox.
To avoid the issue, use a hash of the canonicalized path for the
file as unique identifier, instead of using FileIndex.
This fixes https://github.com/llvm/llvm-project/issues/61401 and
https://github.com/llvm/llvm-project/issues/22079.
Performance wise, this adds (usually) one extra call to
GetFinalPathNameByHandleW for each call to getStatus(). A test
cases such as running clang-scan-deps becomes around 1% slower
by this, which is considered tolerable.
Change the equivalent() function to use getUniqueID instead of
checking individual file_status fields. The
equivalent(Twine,Twine,bool& result) function calls status() on
each path successively, without keeping the file handles open,
which also is prone to such false positives. This also gets rid
of checks of other superfluous fields in the
equivalent(file_status, file_status) function - the unique ID of
a file should be enough (that is what is done for Unix anyway).
This comes with one known caveat: For hardlinks, each name for
the file now gets a different UniqueID, and equivalent() considers
them different. While that's not ideal, occasional false negatives
for equivalent() is usually that fatal (the cases where we strictly
do need to deduplicate files with different path names are quite
rare) compared to the issues caused by false positives for
equivalent() (where we'd deduplicate and omit totally distinct files).
The FileIndex is documented to be stable on NTFS though, so ideally
we could maybe have used it in the majority of cases. That would
require a heuristic for whether we can rely on FileIndex or not.
We considered using the existing function is_local_internal for that;
however that caused an unacceptable performance regression
(clang-scan-deps became 38% slower in one test, even more than that
in another test).
Differential Revision: https://reviews.llvm.org/D155579
This is a new attempt of https://reviews.llvm.org/D159481, this time as
GitHub PR.
`GenericOptionValue::compare()` should return `true` for a match.
- `OptionValueBase::compare()` always returns `false` and shouldn't
match anything.
- `OptionValueCopy::compare()` returns `false` if not `Valid` which
corresponds to no match.
Also adding some tests.
This uses just argv[0] on OpenBSD. OpenBSD does not support the /proc filesystem.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D159168
Add an option in `SpecialCaseList` to use Globs instead of Regex to match patterns. `GlobPattern` was extended in https://reviews.llvm.org/D153587 to support brace expansions which allows us to use patterns like `*/src/foo.{c,cpp}`. It turns out that most patterns only take advantage of `*` so using Regex was overkill and required lots of escaping in practice. This often led to bugs due to forgetting to escape special characters.
Since this would be a breaking change, we temporarily support Regex by default and use Globs when `#!special-case-list-v2` is the first line in the file. Users should switch to the glob format described in https://llvm.org/doxygen/classllvm_1_1GlobPattern.html. For example, `(abc|def)` should become `{abc,def}`.
See discussion in https://reviews.llvm.org/D152762 and https://discourse.llvm.org/t/use-glob-instead-of-regex-for-specialcaselists/71666.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D154014
This revision supports --print-supported-extensions,
it prints out all of the extensions and corresponding version supported.
Reviewed By: craig.topper, kito-cheng
Differential Revision: https://reviews.llvm.org/D146054
Extend `GlobPattern` to support brace expansions, e.g., `foo.{c,cpp}` as discussed in https://reviews.llvm.org/D152762#4425203.
The high level change was to turn `Tokens` into a list that gets larger when we see a new brace expansion term. Then in `GlobPattern::match()` we must check against each token group.
This is a breaking change since `{` will no longer match a literal without escaping. However, `\{` will match the literal `{` before and after this change. Also, from a brief survey of LLVM, it seems that `GlobPattern` is mostly used for symbol and path matching, which likely won't need `{` in their patterns.
See https://github.com/devongovett/glob-match#syntax for a nice glob reference.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D153587
BLAKE3 implementation does not support using arm neon on big-endian hosts: see
blake3_neon.c. Setting `BLAKE3_USE_NEON` to 1 by default for all AArch64
hosts broke builds for big endian hosts. This patch fixes the behavior
by introducing an additional check against `__ARM_BIG_ENDIAN` before
setting `BLAKE3_USE_NEON`.
Differential Revision: https://reviews.llvm.org/D159156
D152495 makes clang warn on unused variables that are declared in conditions like `if (int var = init) {}`
This patch is an NFC fix to suppress the new warning in llvm,clang,lld builds to pass CI in the above patch.
Differential Revision: https://reviews.llvm.org/D158016
