| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
|
|
Current approach generates intrinsic records when users specify
corresponding required features by using command line option.
However it's not able to handle features passed by using target
attributes correctly where each function might have different
features.
This patch resolves this by generating all of intrinsic records which
carry the required features in their function declaration using
attribute and check the required extensions in CheckBuiltinFunctionCall.
This should fix
[56592](https://github.com/llvm/llvm-project/issues/56592),
[134962](https://github.com/llvm/llvm-project/issues/134962) and
[121603](https://github.com/llvm/llvm-project/issues/121603)
|
|
This patch implements clang intrinsic support for XAndesVDot.
The document for the intrinsics can be found at:
https://github.com/andestech/andes-vector-intrinsic-doc/blob/ast-v5_4_0-release-v5/auto-generated/andes-v5/intrinsic_funcs.adoc#andes-vector-dot-product-extensionxandesvdot
and with policy variants
https://github.com/andestech/andes-vector-intrinsic-doc/blob/ast-v5_4_0-release-v5/auto-generated/andes-v5/policy_funcs/intrinsic_funcs.adoc#andes-vector-dot-product-extensionxandesvdot
Co-authored-by: Tony Chuan-Yue Yuan <yuan593@andestech.com>
|
|
This patch implements clang intrinsic support for XAndesVPackFPH.
The document for the intrinsics can be found at:
https://github.com/andestech/andes-vector-intrinsic-doc/blob/ast-v5_4_0-release-v5/auto-generated/andes-v5/intrinsic_funcs.adoc#andes-vector-packed-fp16-extensionxandesvpackfph
and with policy variants
https://github.com/andestech/andes-vector-intrinsic-doc/blob/ast-v5_4_0-release-v5/auto-generated/andes-v5/policy_funcs/intrinsic_funcs.adoc#andes-vector-packed-fp16-extensionxandesvpackfph
Co-authored-by: Tony Chuan-Yue Yuan <yuan593@andestech.com>
|
|
We add comment markers and print enum names instead of numbers.
For required extensions, we print the feature list instead of raw
bits.
This recommits d0cf5cd which was reverted by 21ff45d.
|
|
(#133710)"
This reverts commit d0cf5cd5f9790dc21396936d076389c3be1a9599.
Error: "declaration of ‘clang::RISCV::RequiredExtensions
{anonymous}::SemaRecord::RequiredExtensions’ changes meaning of
‘RequiredExtensions’ [-fpermissive]"
|
|
We add comment markers and print enum names instead of numbers.
For required extensions, we print the feature list instead of raw
bits.
|
|
extensions. NFC (#132895)
We have more than 32 extensions in our downstream and had to change this
type from uint32_t to uint64_t.
To simplify our downstream and make the code more flexible, I propose to
make it an array of uint32_t that we can size based on the number of
extensions. I really wanted to use std::bitset, but we have to print the
bits to a .inc file which can't easily be done with std::bitset.
|
|
Summary:
This patch proposes new llvm types for RISCV vector tuples represented
as `TargetExtType` which contains both `LMUL` and `NF`(num_fields)
information and keep it all the way down to `selectionDAG` to match the
corresponding `MVT`(support in the following patch).
Detail:
Currently we have built-in C types for RISCV vector tuple type, e.g.
`vint32m1x2_t`, however it's is represented as structure of scalable
vector types, i.e. `{<vscale x 2 x i32>, <vscale x 2 x i32>}`. It loses
the information for num_fields(NF) as struct is flattened during
`selectionDAG`, thus it makes it not possible to handle inline assembly
of vector tuple type, it also makes the calling convention of vector
tuple types handing not strait forward and hard to realize the
allocation code, i.e. `RVVArgDispatcher`.
The llvm IR for the example above is then represented as
`target("riscv.vector.tuple", <vscale x 8 x i8>, 2)` in which the first
type parameter is the equivalent size scalable vecotr of i8 element
type, the following integer parameter is the `NF` of the tuple.
The new RISCV specific vector insert/extract intrinsics are also added
as `llvm.riscv.vector.insert` and `llvm.riscv.vector.extract` to handle
tuple type subvector insertion/extraction since the generic ones only
operates on `VectorType` but not `TargetExtType`.
There are total of 32 llvm types added for each `VREGS * NF <= 8`, where
`VREGS` is the vector registers needed for each `LMUL` and `NF` is
num_fields.
The name of types are:
```
target("riscv.vector.tuple", <vscale x 1 x i8>, 2) // LMUL = mf8, NF = 2
target("riscv.vector.tuple", <vscale x 1 x i8>, 3) // LMUL = mf8, NF = 3
target("riscv.vector.tuple", <vscale x 1 x i8>, 4) // LMUL = mf8, NF = 4
target("riscv.vector.tuple", <vscale x 1 x i8>, 5) // LMUL = mf8, NF = 5
target("riscv.vector.tuple", <vscale x 1 x i8>, 6) // LMUL = mf8, NF = 6
target("riscv.vector.tuple", <vscale x 1 x i8>, 7) // LMUL = mf8, NF = 7
target("riscv.vector.tuple", <vscale x 1 x i8>, 8) // LMUL = mf8, NF = 8
target("riscv.vector.tuple", <vscale x 2 x i8>, 2) // LMUL = mf4, NF = 2
target("riscv.vector.tuple", <vscale x 2 x i8>, 3) // LMUL = mf4, NF = 3
target("riscv.vector.tuple", <vscale x 2 x i8>, 4) // LMUL = mf4, NF = 4
target("riscv.vector.tuple", <vscale x 2 x i8>, 5) // LMUL = mf4, NF = 5
target("riscv.vector.tuple", <vscale x 2 x i8>, 6) // LMUL = mf4, NF = 6
target("riscv.vector.tuple", <vscale x 2 x i8>, 7) // LMUL = mf4, NF = 7
target("riscv.vector.tuple", <vscale x 2 x i8>, 8) // LMUL = mf4, NF = 8
target("riscv.vector.tuple", <vscale x 4 x i8>, 2) // LMUL = mf2, NF = 2
target("riscv.vector.tuple", <vscale x 4 x i8>, 3) // LMUL = mf2, NF = 3
target("riscv.vector.tuple", <vscale x 4 x i8>, 4) // LMUL = mf2, NF = 4
target("riscv.vector.tuple", <vscale x 4 x i8>, 5) // LMUL = mf2, NF = 5
target("riscv.vector.tuple", <vscale x 4 x i8>, 6) // LMUL = mf2, NF = 6
target("riscv.vector.tuple", <vscale x 4 x i8>, 7) // LMUL = mf2, NF = 7
target("riscv.vector.tuple", <vscale x 4 x i8>, 8) // LMUL = mf2, NF = 8
target("riscv.vector.tuple", <vscale x 8 x i8>, 2) // LMUL = m1, NF = 2
target("riscv.vector.tuple", <vscale x 8 x i8>, 3) // LMUL = m1, NF = 3
target("riscv.vector.tuple", <vscale x 8 x i8>, 4) // LMUL = m1, NF = 4
target("riscv.vector.tuple", <vscale x 8 x i8>, 5) // LMUL = m1, NF = 5
target("riscv.vector.tuple", <vscale x 8 x i8>, 6) // LMUL = m1, NF = 6
target("riscv.vector.tuple", <vscale x 8 x i8>, 7) // LMUL = m1, NF = 7
target("riscv.vector.tuple", <vscale x 8 x i8>, 8) // LMUL = m1, NF = 8
target("riscv.vector.tuple", <vscale x 16 x i8>, 2) // LMUL = m2, NF = 2
target("riscv.vector.tuple", <vscale x 16 x i8>, 3) // LMUL = m2, NF = 3
target("riscv.vector.tuple", <vscale x 16 x i8>, 4) // LMUL = m2, NF = 4
target("riscv.vector.tuple", <vscale x 32 x i8>, 2) // LMUL = m4, NF = 2
```
RFC:
https://discourse.llvm.org/t/rfc-support-riscv-vector-tuple-type-in-llvm/80005
|
|
|
|
constructor. NFC (#98067)
Looks like the usage was removed by
7a5cb15ea6facd82756adafae76d60f36a0b60fd
|
|
This patch optimize:
1. Reduce string size of RVVIntrinsicDef.
2. Reduce the type size of the index of intrinsics.
I use valgrind --tool=massif to analyze a simple program:
```
#include <riscv_vector.h>
vint32m1_t test(vint32m1_t v1, vint32m1_t v2, size_t vl) {
return __riscv_vadd(v1, v2, vl);
}
```
and before optimization, the peak memory usage is 15.68MB,
after optimization, the peak memory usage is 13.69MB.
|
|
Builtins.def says that bfloat should be represented by the 'y'
character, not the 'b' character. The 'b' character is specified to
represent boolean. The implementation currently uses 'b' correctly for
boolean and incorrectly re-uses 'b' for bfloat.
This was not caught since no builtins are emitted in
build/tools/clang/include/clang/Basic/riscv_sifive_vector_builtins.inc.
Don't know that we can test this without creating builtins that expose
this issue, although I'm not sure we really want to do that.
|
|
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>
|
|
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.
|
|
This PR attempts to recommit the PR (#72216) with a safe-bounded TypeID
that will not cause indeterminate results for the compiler.
|
|
This reverts commit 8434b0b9d39b7ffcd1f7f7b5746151e293620e0d. #72216
This commit broke the multiple buildbots, looks like the extension in
`NUM_PREDEF_TYPE_IDS` might have broken some inheriting usages, causing
indeterminate results for the compiler. Investigating the issue now.
|
|
The first commit extends the capacity from the compiler infrastructure,
and the second commit continues the effort in #71140 to introduce tuple
types for bfloat16.
|
|
BF16 implementation based on @joshua-arch1's
https://reviews.llvm.org/D152498
Fixed the incorrect f16 type introduced in
https://github.com/llvm/llvm-project/pull/68296
---------
Co-authored-by: Jun Sha (Joshua) <cooper.joshua@linux.alibaba.com>
|
|
FP32-to-int8 Ranged Clip Instructions
https://sifive.cdn.prismic.io/sifive/0aacff47-f530-43dc-8446-5caa2260ece0_xsfvfnrclipxfqf-spec.pdf
|
|
These source files do not use StringMap.h.
|
|
Depends on D141672, D138809
Differential Revision: https://reviews.llvm.org/D138810
|
|
This patch does a few things:
1. Add a new type called Undefined to ScalarTypeKind.
2. Make RVVType::applyModifier early return when encounter invalid
ScalarType, otherwise it could be modified to "non-invalid" type in the following code.
3. When FixedLMULType::SmallerThan is applied, the lmul should be "<" than
specified one, so lmuls which are ">=" should be marked as invalid.
Differential Revision: https://reviews.llvm.org/D156223
|
|
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155102
|
|
/data/llvm-project/clang/include/clang/Support/RISCVVIntrinsicUtils.h:390:8: error: private field 'HasFRMRoundModeOp' is not used [-Werror,-Wunused-private-field]
bool HasFRMRoundModeOp;
^
1 error generated.
|
|
Depends on D152879.
Specification PR: riscv-non-isa/rvv-intrinsic-doc#226
This patch adds variant of `vfadd` that models the rounding mode control.
The added variant has suffix `_rm` appended to differentiate from the
existing ones that does not alternate `frm` and uses whatever is inside.
The value `7` is used to indicate no rounding mode change. Reusing the
semantic from the rounding mode encoding for scalar floating-point
instructions.
Additional data member `HasFRMRoundModeOp` is added so we can append
`_rm` suffix for the fadd variants that models rounding mode control.
Additional data member `IsRVVFixedPoint` is added so we can define
pseudo instructions with rounding mode operand and distinguish the
instructions between fixed-point and floating-point.
Reviewed By: craig.topper, kito-cheng
Differential Revision: https://reviews.llvm.org/D152996
|
|
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D154693
|
|
This is the 3rd patch of the patch-set. For the cover letter, please
checkout D152069.
Depends on D152070.
This patch expands all variants of unit stride segment load, including
the policy variants. This patch also fixes the trailing suffix in the
intrinsics' function name that representing the return type, adding
`x{NF}`.
Currently the tuple type co-exists with the non-tuple type intrinsics.
Since the co-existance is temporary, this patch only adds test cases of
all variants for vlseg2e32 to show the capability done.
Test cases of other data type and NF will be added in the patch-set
when the replacement happens.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D152071
|
|
This is the 2nd patch of the patch-set. For the cover letter, please
checkout D152069.
Depends on D152069.
This patch also removes redundant checks related to tuples and dedicate
the check to happen in `RVVType::verifyType`.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D152070
|
|
For the cover letter of this patch-set, please checkout D146872.
Depends on D147915.
This is the 10th patch of the patch-set.
This patch is a proof-of-concept and will be extended to full coverage
in the future. Only vget for tuple type of NF=2, EEW=32, LMUL=1 is
defined now.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D147916
|
|
Signed-off by: eop Chen <eop.chen@sifive.com>
|
|
type variant of vlseg2e32
For the cover letter of this patch-set, please checkout D146872.
Depends on D146873.
This is the 3rd patch of the patch-set. This patch originates from
D99593.
Note: This patch is a proof-of-concept and will be extended to full
coverage in the future. Currently, the old non-tuple unit-stride
segment load is not removed, and only signed integer unit-strided
segment load of NF=2, EEW=32 is defined here.
When replacing the old intrinsics, the extra `IsTuple` parameter under
various places will be redundant and removed.
Authored-by: eop Chen <eop.chen@sifive.com>
Co-Authored-by: Hsiangkai Wang <kai.wang@sifive.com>
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D147731
|
|
This commit adds prefix for the overloaded RVV intrinsics.
This is the 3rd commit of a patch-set to add __riscv_ for all RVV
intrinsics.
This follows the naming guideline under riscv-c-api-doc to add the
`__riscv_` suffix for all RVV intrinsics.
Pull Request:
riscv-non-isa/riscv-c-api-doc#31
riscv-non-isa/rvv-intrinsic-doc#189
Depends on D142644.
Reviewed By: kito-cheng
Differential Revision: https://reviews.llvm.org/D142697
|
|
This commit adds prefix for the non-overloaded RVV intrinsics.
This is the 2nd commit of a patch-set to add __riscv_ for all RVV
intrinsics.
This follows the naming guideline under riscv-c-api-doc to add the
`__riscv_` suffix for all RVV intrinsics.
Pull Request:
riscv-non-isa/riscv-c-api-doc#31
riscv-non-isa/rvv-intrinsic-doc#189
Depends on D142085.
Reviewed By: kito-cheng
Differential Revision: https://reviews.llvm.org/D142644
|
|
This reverts commit 2153544865a9733b06579823814c981f735e4201.
Buildbot failure https://lab.llvm.org/buildbot#builders/139/builds/35218
shows left-out test cases that were not updated.
|
|
This commit adds prefix for the non-overloaded RVV intrinsics.
This is the 2nd commit of a patch-set to add __riscv_ for all RVV
intrinsics.
This follows the naming guideline under riscv-c-api-doc to add the
`__riscv_` suffix for all RVV intrinsics.
Pull Request:
riscv-non-isa/riscv-c-api-doc#31
riscv-non-isa/rvv-intrinsic-doc#189
Depends on D142085.
Reviewed By: kito-cheng
Differential Revision: https://reviews.llvm.org/D142644
|
|
This patch works towards the simplification proposal [0] of Nick
Knight. After this patch, we have reduced the hierarchy of intrinsics
from two sets (non-policy and policy) into a single set, with a general
assumption that policy behavior is agnostic unless specified.
[0] https://gist.github.com/nick-knight/6cb0b74b351a25323dfb1821d3a269b9
Pull Request: riscv-non-isa/rvv-intrinsic-doc#186.
Depends on D141796.
Reviewed By: craig.topper, kito-cheng
Differential Revision: https://reviews.llvm.org/D142016
|
|
This reverts commit 2b807336ad385e64a7d182d5fb67bdfe449707a3.
This change is causing Windows builds to hang and out of memory errors with clang-15:
- https://lab.llvm.org/buildbot/#/builders/17/builds/33129
- https://lab.llvm.org/buildbot/#/builders/174/builds/17069
- https://lab.llvm.org/buildbot/#/builders/83/builds/28484
- https://lab.llvm.org/buildbot/#/builders/172/builds/22803
- https://lab.llvm.org/buildbot/#/builders/216/builds/16210
|
|
The object is now correct by construction.
This is the 15th commit of a patch-set that aims to change the default policy
for RVV intrinsics from TAMU to TAMA.
Please refer to the cover letter in the 1st commit (D141573) for an
overview.
Depends on D141793.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D141796
|
|
After this commit, the non-policy variants of `vid` and `viota` are no
longer available for an oveloaded version since the default policy is
now TAMA and the masked-off operand is removed.
Be noted that ALL RVV intrinsics now operate under the general
assumption that a policy behavior is "agnostic" unless specified.
Therefore this patch also changes the semantic of policy intrinsics
with the suffix of `_ta` and `tu`. These intrinsics don't have their
mask policy specified and was assumed to be undisturbed. It is now
changed to agnostic.
This is the 14th commit of a patch-set that aims to change the default policy
for RVV intrinsics from TAMU to TAMA.
Please refer to the cover letter in the 1st commit (D141573) for an
overview.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D141793
|
|
The attribute can be removed now as preceding patches have removed its
users.
This is the 11th commit of a patch-set that aims to change the default policy
for RVV intrinsics from TAMU to TAMA.
Please refer to the cover letter in the 1st commit (D141573) for an
overview.
Reviewed By: craig.topper, kito-cheng
Differential Revision: https://reviews.llvm.org/D141768
|
|
always tail agnostic
The logic under `computeBuiltinTypes` is an amendment to setting Policy as
`Omit`. The tail policy should be set to agnostic for those intrinsics that
has `HasTailPolicy = false`, which are the intrinsics with a mask destination
register.
This is the 6th commit of a patch-set that aims to change the default policy
for RVV intrinsics from TAMU to TAMA.
Please refer to the cover letter in the 1st commit (D141573) for an
overview.
Reviewed By: craig.topper, kito-cheng
Differential Revision: https://reviews.llvm.org/D141756
|
|
by reusing HasTailPolicy and HasMaskPolicy
Righteously there shouldn't be any special cases here because
`HasTailPolicy` and `HasMaskPolicy` is able to express necessary cases.
This commit is a part of the step-by-step effort to remove
`Policy::Scheme::Omit`, which completely does not make sense in RVV 1.0
because an RVV instruction always executes with `vta` and `vma` set
to a certain value.
This is the 5th commit of a patch-set that aims to change the default policy
for RVV intrinsics from TAMU to TAMA.
Please refer to the cover letter in the 1st commit (D141573) for an
overview.
Reviewed By: craig.topper, kito-cheng
Differential Revision: https://reviews.llvm.org/D141754
|
|
RVVIntrinsic::computeBuiltinTypes
`PolicyAttrs::IsUnspecified` is modified in
`RVV::Intrinsic::computeBuiltInTypes` and used under
`RVVIntrinsic::updateNamesAndPolicy`. Suprisingly the modification
in `RVV::Intrinsic::computeBuiltInTypes` is completely unnecessary.
This commit removes the redundant logic.
This is the 4th commit of a patch-set that aims to change the default policy
for RVV intrinsics from TAMU to TAMA.
Please refer to the cover letter in the 1st commit (D141573) for an
overview.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D141577
|
|
RVVIntrinsic::getSupportedMaskedPolicies for clarity
This is the 3rd commit of a patch-set that aims to change the default policy
for RVV intrinsics from TAMU to TAMA.
Please refer to the cover letter in the 1st commit (D141573) for an
overview.
Reviewed By: kito-cheng
Differential Revision: https://reviews.llvm.org/D141575
|
|
The original naming is inaccurate. An RVV intrinsic always comes with
a corresponding policy behavior. When the policy is unspecified for an
intrinsic, its policy behavior should be it's default assumption.
This is the 2nd commit of a patch-set that aims to change the default policy
for RVV intrinsics from TAMU to TAMA.
Please refer to the cover letter in the 1st commit (D141573) for an
overview.
Reviewed By: kito-cheng
Differential Revision: https://reviews.llvm.org/D141574
|
|
This is the 1st commit of a patch-set that aims to change the default policy
for RVV intrinsics from TAMU to TAMA.
The patch-set work towards the simplification proposal [0] of Nick
Knight. After this patch-set, all intrinsics operates under a general
assumption that the policy behavior is agnostic.
You may find that most of the patches are NFC patches. They subtly remove
implicit assumptions that entangles the codebase, making the singular patch
that contains functional change clear and obvious.
In [2/15], The attribute `Policy::IsPolicyNone` may give the mis-perception
that an RVV intrinsic may operate without any policy. However this is not the
case because the policy CSR-s (`vta` and `vma`) always affect an RVV
instruction's behavior, except that some instructions have policy always set
as agnostic (e.g. instructions with a mask destination register is always
tail agnostic).
Next, to perform the change from TAMU to TAMA, we need to first remove
`Policy::PolicyType::Omit`. [4/15] ~ [12/15] removes it with NFC patches step
by step. Without the patches, directly applying [14/15] to the existing codebase
will not work because there will be complicated logics that are scattered in
places that is hard to maintain.
[1/15], [3/15] are not related to the main goal of this patch-set, they were
clean-up along the way as I was going through the codebase. [13/15] is a
clean-up that was an oversight in D141198.
Finally, [14/15] performs the functional change this patch-set aims for. The
default policy is changed from TAMU to TAMA. This affects the masked version of
the intrinsics without a policy suffix. The masked-off operand is removed. Due
to the removal, masked version of `vid` and `viota` intrinsics are no longer
available for overloading.
[15/15] is a final commit to set data members of `Policy` as constants. Through
the refactoring the class `Policy` is now correct-by-construction.
The next patch-set will be to remove redundant intrinsics with a policy suffix
`_ta` and `_tama` intrinsics are redundant and will be removed. Other policy
suffix will be renamed to adapt to the general assumption that policy is
generally agnostic.
[0] https://gist.github.com/nick-knight/6cb0b74b351a25323dfb1821d3a269b9
Pull Request: riscv-non-isa/rvv-intrinsic-doc#186
Reviewed By: craig.topper, kito-cheng
Differential Revision: https://reviews.llvm.org/D141573
|
|
This is the 7th commit of a patch-set that aims to remove the
IsPrototypeDefaultTU special case for the rvv-intrinsics.
This is the final commit of the patch-set. Now that no intrinsics is
using the attribute, we are safe to remove it.
Please refer to the cover letter in the 1st commit (D140895) for an
overview.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D140954
|
|
From:
vint32m1_t vmerge_vvm_i32m1 (vbool32_t mask, vint32m1_t op1, vint32m1_t op2, size_t vl);
vint32m1_t vcompress_vm_i32m1 (vbool32_t mask, vint32m1_t src, size_t vl);
To:
vint32m1_t vmerge_vvm_i32m1 (vint32m1_t op1, vint32m1_t op2, vbool32_t selector, size_t vl);
vint32m1_t vcompress_vm_i32m1 (vint32m1_t src, vbool32_t selector, size_t vl);
Address issues:
riscv-non-isa/rvv-intrinsic-doc#140
riscv-non-isa/rvv-intrinsic-doc#167
Pull request:
riscv-non-isa/rvv-intrinsic-doc#185
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D140686
|
|
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
|
