This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
Introduce a RVVTypeCache to hold the cache instead of using a local
static variable to maintain a cache.
Also made construct of RVVType to private, make sure that could be only
created by a cache manager.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D138429
TableGen executables are supposed to never be linked against libLLVM-*.so,
even when LLVM_LINK_LLVM_DYLIB=ON, presumably for cross-compilation.
It turns out that clang-tblgen *did* link against libLLVM-*.so,
indirectly so via the clangSupport.
This lead to a regression in what should have been unrelated work of
cleaning up ManagedStatics in LLVMSupport. A running clang-tblgen
process ended up with two copies of a cl::opt static global:
- one from libLLVMSupport linked statically into clang-tblgen as a
direct dependency
- one from libLLVMSupport linked into libLLVM-*.so, which clang-tblgen
linked against due to the clangSupport dependency
For a bit more context, see the discussion at
https://discourse.llvm.org/t/flang-aarch64-dylib-buildbot-need-help-understanding-a-regression-in-clang-tblgen/64871/
None of the potential solutions I could find are perfect. Presumably one
possible solution would be to remove "Support" from the explicit
dependencies of clang-tblgen. However, relying on the transitive
inclusion via clangSupport seems risky, and in any case this wouldn't
address the issue of clang-tblgen surprisingly linking against libLLVM-*.so.
This change instead creates a second version of the clangSupport library
that is explicitly linked statically, to be used by clang-tblgen.
v2:
- define an alias so that clang-tblgen can always link against
"clangSupport_tablegen"
- use add_llvm_library(... BUILDTREE_ONLY ...)
v3:
- use the object library version of clangSupport if available
Differential Revision: https://reviews.llvm.org/D134637
Instructions.
We will switch all UndefValue to PoisonValue in follow up patches.
Thanks for Kito to help on verification with their interanl testsuite.
Reviewed By: kito-cheng
Differential Revision: https://reviews.llvm.org/D126748
vcompress.
We will switch all UndefValue to PoisonValue in follow up patches.
Reviewed By: kito-cheng
Differential Revision: https://reviews.llvm.org/D126745
1. Add policy functions support and tests for vadd, vmv, vfmv and all load
instructions except segment load. I didn't add all combination of policy
functions in test because it seem not to make sense.
2. Rename HasUnMaskedOverloaded to SupportOverloading.
3. vmv.s.x for ta policy could not have overloaded API.
4. This patch does not support all operations, I will have other follow-up
patches support all.
[RFC] https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/137
Reviewed By: kito-cheng, fakepaper56, fakepaper56
Differential Revision: https://reviews.llvm.org/D126742
Remove MaskedPrototype and add several fields in RVVIntrinsicRecord,
compute Prototype in runtime.
Reviewed By: rogfer01
Differential Revision: https://reviews.llvm.org/D126741
Leverage the method OpenCL uses that adds C intrinsics when the lookup
failed. There is no need to define C intrinsics in the header file any
more. It could help to avoid the large header file to speed up the
compilation of RVV source code. Besides that, only the C intrinsics used
by the users will be added into the declaration table.
This patch is based on https://reviews.llvm.org/D103228 and inspired by
OpenCL implementation.
### Experimental Results
#### TL;DR:
- Binary size of clang increase ~200k, which is +0.07% for debug build and +0.13% for release build.
- Single file compilation speed up ~33x for debug build and ~8.5x for release build
- Regression time reduce ~10% (`ninja check-all`, enable all targets)
#### Header size change
```
| size | LoC |
------------------------------
Before | 4,434,725 | 69,749 |
After | 6,140 | 162 |
```
#### Single File Compilation Time
Testcase:
```
#include <riscv_vector.h>
vint32m1_t test_vadd_vv_vfloat32m1_t(vint32m1_t op1, vint32m1_t op2, size_t vl) {
return vadd(op1, op2, vl);
}
```
##### Debug build:
Before:
```
real 0m19.352s
user 0m19.252s
sys 0m0.092s
```
After:
```
real 0m0.576s
user 0m0.552s
sys 0m0.024s
```
~33x speed up for debug build
##### Release build:
Before:
```
real 0m0.773s
user 0m0.741s
sys 0m0.032s
```
After:
```
real 0m0.092s
user 0m0.080s
sys 0m0.012s
```
~8.5x speed up for release build
#### Regression time
Note: the failed case is `tools/llvm-debuginfod-find/debuginfod.test` which is unrelated to this patch.
##### Debug build
Before:
```
Testing Time: 1358.38s
Skipped : 11
Unsupported : 446
Passed : 75767
Expectedly Failed: 190
Failed : 1
```
After
```
Testing Time: 1220.29s
Skipped : 11
Unsupported : 446
Passed : 75767
Expectedly Failed: 190
Failed : 1
```
##### Release build
Before:
```
Testing Time: 381.98s
Skipped : 12
Unsupported : 1407
Passed : 74765
Expectedly Failed: 176
Failed : 1
```
After:
```
Testing Time: 346.25s
Skipped : 12
Unsupported : 1407
Passed : 74765
Expectedly Failed: 176
Failed : 1
```
#### Binary size of clang
##### Debug build
Before
```
text data bss dec hex filename
335261851 12726004 552812 348540667 14c64efb bin/clang
```
After
```
text data bss dec hex filename
335442803 12798708 552940 348794451 14ca2e53 bin/clang
```
+253K, +0.07% code size
##### Release build
Before
```
text data bss dec hex filename
144123975 8374648 483140 152981763 91e5103 bin/clang
```
After
```
text data bss dec hex filename
144255762 8447296 483268 153186326 9217016 bin/clang
```
+204K, +0.13%
Authored-by: Kito Cheng <kito.cheng@sifive.com>
Co-Authored-by: Hsiangkai Wang <kai.wang@sifive.com>
Reviewed By: khchen, aaron.ballman
Differential Revision: https://reviews.llvm.org/D111617
It's violate coding guideline in LLVM coding standard[1], because the the initialization order is nondeterministic and that might increase the launch time of programs.
However these variables are only used to cache query result, so we can move these variables into the function,, that which resolve both issue: 1. initialized in deterministic order, 2. Initialized that when the first time used.
[1] https://llvm.org/docs/CodingStandards.html#do-not-use-static-constructors
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D128726
This patch does the same thing as D125886 did.
- Use `Overloaded` rather than `Mangled`.
- Use `Prototype` or `Desc` rather than `Seq`, it's not just a string
sequence.
Reviewed By: fakepaper56
Differential Revision: https://reviews.llvm.org/D126634
This NFC patch is splited from D111617.
Using llvm::ArrayRef rather than llvm::SmallVector, ArrayRef is more generic
interface that could accept both llvm::ArrayRef and llvm::SmallVector.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D125893
LMULType always manipulate on Log2LMUL, let all manipulations go
through LMULType::MulLog2LMUL.
Reviewed By: khchen
Differential Revision: https://reviews.llvm.org/D126042
This patch is preparation for D111617, use class/struct/enum rather than char/StringRef to present internal information as possible, that provide more compact way to store those info and also easier to serialize/deserialize.
And also that improve readability of the code, e.g. "v" vs TypeProfile::Vector.
Reviewed By: khchen
Differential Revision: https://reviews.llvm.org/D124730
We add a new clang library called `clangSupport` for putting those utils which can be used in clang table-gen and other clang component.
We tried to put that into `llvm/Support`, but actually those stuffs only used in clang* and clang-tblgen, so I think that might be better to create `clang/Support`
* clang will used that in https://reviews.llvm.org/D111617.
Reviewed By: khchen, MaskRay, aaron.ballman
Differential Revision: https://reviews.llvm.org/D121984
Kazu Hirata