We have two structs for representing the version of an extension in
RISCVISAInfo, RISCVExtensionInfo and RISCVExtensionVersion, both
with the exact same fields. This patch deduplicates them.
This reverts commit fb7fe49960ae053c92985f3376d85a15bbd10d1a.
The commit introduced a bug where an option with the `All' subcommand
would not be added to a category initialized after that option.
After #75679, it is no longer necessary to add the `All` pseudo
subcommand to the list of registered subcommands. The change causes the
list to contain only real subcommands, i.e. an unnamed top-level
subcommand and named ones. This simplifies the code a bit by removing
some checks for this special case.
toFeatures and toFeatureVector both output a list of target feature
flags, just with a slightly different interface. toFeatures keeps any
unsupported extensions, and also provides a way to append negative
extensions (AddAllExtensions=true).
This patch combines them into one function, so that a later patch will
be be able to get a std::vector of features that includes all the
negative extensions, which was previously only possible through the
StrAlloc interface.
If a category has no options associated with it, the `--help-hidden`
command still shows that category with the annotation "This option
category has no options", and this is how it was implemented from the
beginning when the categories were introduced, see commit 0537a98878. A
feature to hide unrelated options was added later, in
https://reviews.llvm.org/D7100. Now, if a tool needs to hide unrelated
options that are associated with categories, leaving some of them empty,
those categories will still be visible on the `--help-hidden` output,
even if they have no use for the tool; see the changes in
`llvm/test/tools/llvm-debuginfo-analyzer/cmdline.test` for an example.
The patch ensures that only categories with options are shown on both
main and hidden help output.
The patch adds the instructions in Zicfiss extension. Zicfiss extension
is to support shadow stack for control flow integrity. This patch is
based on version [0.3.1].
[0.3.1]: https://github.com/riscv/riscv-cfi/releases/tag/v0.3.1
This reverts 0d3eee33f262402562a1ff28106dbb2f59031bdb and
4c37d30e22ae655394c8b3a7e292c06d393b9b44.
XSfcie is not an official SiFive extension name. It stands for
SiFive Custom Instruction Extension, which is mentioned in the S76
manual, but then elsewhere in the manual says it is not supported
for S76.
LLVM had various instructions and CSRs listed as part of this
extension, but as far as SiFive is concerned, none of them are part
of it. There are no documented extension names for these instructions
and CSRs either externally or internally.
If these are important to LLVM users, I can facilitate creating
extension names for them and have them documented. For now I'm
removing everything.
Unfortunately, these instructions and CSRs are in LLVM 17 so this
is an incompatible change.
This makes the Windows implementation for `getMainExecutable()` behave
the same as its Linux counterpart, in regards to symlinks. Previously,
when using `cmake ... -DLLVM_USE_SYMLINKS=ON`, calling this function
wouldn't resolve to the "real", non-symlinked path.
This implements experimental support for the Zimop extension as
specified here:
https://github.com/riscv/riscv-isa-manual/blob/main/src/zimop.adoc.
This change adds only assembly support.
---------
Co-authored-by: ln8-8 <lyut.nersisyan@gmail.com>
Co-authored-by: ln8-8 <73429801+ln8-8@users.noreply.github.com>
Zvfbfmin does not have any scalar operands making this an unnecessary
dependency. The spec was just updated to remove this. See
86d7a74f4b
This fixes a correctness issue where Xsfvfwmaccqqq was incorrectly
depending on Zfbfmin. The SiFive CPUs that support Xsfvfwmaccqqq do not
implement Zfbfmin, but do implement Zvfbfmin based on a previous
understanding that it only requires Zve32f. I've added tests for this
feature to raise the bar for adding dependencies to it in the future.
The patch adds a helper method to iterate over all subcommands to which
an option belongs. Duplicate code is removed and replaced with calls to
this new method.
The RISC-V vector crypto extensions have been ratified. This patch
updates the Clang and LLVM support for these extensions to be
non-experimental, while leaving the C intrinsics as experimental since
the C intrinsics are not yet standardized.
Co-authored-by: Brandon Wu <brandon.wu@sifive.com>
Now we have default abi lp64 for rv64if and ilp32 for rv32if, which is
different with riscv-gnu-toolchain. In
8e9fb09a0c/configure (L3385)
when have f and not d, it prefers lp64f/ilp32f but no soft float. This
patch tries to make their behaviors consistent.
Crash identified internally in lld's use of StringMap in
`compareSections`. Will investigate offline before recommitting.
This reverts commit 67c631d283fc96d652304199cd625be426b98f8e.
Underlying StringMap API for providing a hash has caused some problems
(observed a crash in lld) - so reverting this until I can figure out/fix
what's going on there.
This reverts commit 52ba075571958e2fec8d871ddfa1ef56486b86d3.
This reverts commit 2e197602305be18b963928e6ae024a004a95af6d.
```
[136/6185] Building CXX object lib\Support\CMakeFiles\LLVMSupport.dir\raw_ostream.cpp.obj
C:\Work\david.spickett\llvm-project\llvm\lib\Support\raw_ostream.cpp(977,23): warning: missing field 'wHighVersion' initializer [-Wmissing-field-initializers]
977 | WSADATA WsaData = {0};
| ^
```
According to
https://learn.microsoft.com/en-us/windows/win32/api/winsock/ns-winsock-wsadata
this can have any number of fields depending on some ifdefs,
so I've replaced `{0}` with a memset of whatever the size happens to be.
Probably doesn't matter for correctness anyway, but the compiler
won't see it used uninitialised at least.
This originally used the spelling Ws2_32 when added in
a5ffabce98a4b2e9d69009fa3e60f2b154100860, but was changed to WS2_32
in 042a2e8932984e6c9f2017cbabb5bc66ad5419ce with the intent to
use the canonical spelling from WinSDK, in order to aid cross
compilation from case sensitive file systems with WinSDK.
However, the WinSDK itself is self-inconsistent with respect
to file name cases. Headers refer to each other with many different
casings, so the original, out of the box casing doesn't work
on case sensitive file systems. Import libraries like these
use a variety of casings (some use all lowercase, some use
CamelCase, some all uppercase, and the suffix is either .lib,
.Lib or .LIB).
In order to use the WinSDK on a case sensitive file system, these
case issues has to be worked around somehow. Either by lowercasing
all files (and the #includes within them, and potentially keeping
symlinks with their original casing), or by setting up a Clang
case insensitive VFS overlay. LLVM's llvm/cmake/platforms/WinMsvc.cmake
sets up such a VFS overlay. For the linker, it creates a directory
with lowercase symlinks.
Therefore, the canonical way of handling these casing issues on
case sensitive file systems is to consistently use lowercase. That
is also what MinGW toolchains use.
As an example, the same list of system_libs refers to advapi32,
even if the actual file on disk in WinSDK is AdvAPI32.Lib.
Likewise, other in-tree build systems that picked up this change
for ws2_32 made it all lowercase, in
b07aaf8d3bde911638b0370037204898c3c2deb7 and
d22dad9f768fef376546053952f0b49b23bebfde. This also matches other
existing references to ws2_32 in e.g.
lldb/source/Plugins/Process/Windows/Common/CMakeLists.txt and
lldb/source/Utility/CMakeLists.txt.
The file name is WS2_32.Lib in all the Windows SDK versions I looked at.
You can get away with the incorrect casing on a case-insensitive file
system but it can matter for cross-compilation.
This patch fixed the following compile error caused by #73603.
```
llvm/lib/Support/raw_ostream.cpp: In static member function ‘static llvm::Expected<llvm::ListeningSocket> llvm::ListeningSocket::createUnix(llvm::StringRef, int)’:
llvm/lib/Support/raw_ostream.cpp:1040:10: error: could not convert ‘ListenSocket’ from ‘llvm::ListeningSocket’ to ‘llvm::Expected<llvm::ListeningSocket>’
return ListenSocket;
^~~~~~~~~~~~
```
The patch improves the reporting for the first option in the command
line when it looks like a subcommand name but does not match any
defined.
Before the patch:
```
> prog baz
prog: Unknown command line argument 'baz'. Try: 'prog --help'
```
With the patch:
```
> prog baz
prog: Unknown subcommand 'baz'. Try: 'prog --help'
prog: Did you mean 'bar'?
```
This patch resolves the following errors on z/OS:
error: no member named 'wait4' in the global namespace
error: no member named 'ru_maxrss' in 'rusage'
error: use of undeclared identifier 'strsignal'
error: Cannot get usage times on this platform
error: Cannot get malloc info on this platform
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
Useful for lldb's const string pool, using the hash to determine which
string map to lock and query/insert.
Derived from https://reviews.llvm.org/D122974 by Luboš Luňák
https://reviews.llvm.org/D154014 addes glob support and enables it when
`#!special-case-list-v2` is the first line. This patch makes the glob
support the default (faster than regex after
https://reviews.llvm.org/D156046) and switches to the deprecated regex
support if `#!special-case-list-v1` is the first line.
I have surveyed many ignore lists. All ignore lists I find only use
basic `*` `.` and don't use regex metacharacters such as `(` and `)`.
(As neither `src:` nor `fun:` benefits from using regex.)
They are unaffected by the transition (with a caution that regex
`src:x/a.pb.*` matches `x/axpbx` but glob `src:x/a.pb.*` doesn't).
There is no deprecating warning. If a user finds
`#!special-case-list-v1`, they shall read that the old syntax is
deprecated.
Link:
https://discourse.llvm.org/t/use-glob-instead-of-regex-for-specialcaselists/71666
This patch renames {starts,ends}with to {starts,ends}_with for
consistency with std::{string,string_view}::{starts,ends}_with in
C++20. Since there are only a handful of occurrences, this patch
skips the deprecation phase and simply renames them.
When a tool defines only one or two subcommands, the `[subcommand]` part
is not displayed in the `USAGE` help line. Note that a similar issue
for printing the list of the subcommands has been fixed in
https://reviews.llvm.org/D25463.
A zero-length StringRef can have a null data pointer, which, if passed to the llvm_regex functions which take a pointer+length, but then convert it into a [begin, end) pointer pair can cause a nullptr+0 expression to be evaluated, which is UB. So avoid that by ensuring the data pointer is always non-null, even in the zero-length case.
Fixed build bot errors.
- Use `StackOption<std::string>` type for the top level option. This
way, a per test-case option is unregistered when destructor of
`StackOption` cleans up state for subsequent test cases.
- Repro the crash with no test sharding `/usr/bin/python3
/path/to/llvm-project/build/./bin/llvm-lit -vv --no-gtest-sharding -j128
/path/to/llvm-project/llvm/test/Unit`. The crash is gone with the fix
(same no-sharding repro)
**Original commit message:**
**Context:**
- In https://lists.llvm.org/pipermail/llvm-dev/2016-June/101804.html and
commit
07670b3e98,
`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.
