[clang] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

This is p

[clang] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

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

show more ...

[clang] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Option

[clang] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optional with
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

show more ...

[clang] Use a StringRef instead of a raw char pointer to store builtin and call information

This avoids recomputing string length that is already known at compile time.

It has a slight impact on pr

[clang] Use a StringRef instead of a raw char pointer to store builtin and call information

This avoids recomputing string length that is already known at compile time.

It has a slight impact on preprocessing / compile time, see

https://llvm-compile-time-tracker.com/compare.php?from=3f36d2d579d8b0e8824d9dd99bfa79f456858f88&to=e49640c507ddc6615b5e503144301c8e41f8f434&stat=instructions:u

This a recommit of e953ae5bbc313fd0cc980ce021d487e5b5199ea4 and the subsequent fixes caa713559bd38f337d7d35de35686775e8fb5175 and 06b90e2e9c991e211fecc97948e533320a825470.

The above patchset caused some version of GCC to take eons to compile clang/lib/Basic/Targets/AArch64.cpp, as spotted in aa171833ab0017d9732e82b8682c9848ab25ff9e.
The fix is to make BuiltinInfo tables a compilation unit static variable, instead of a private static variable.

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

show more ...

[RISCV] Adjust RV64I data layout by using n32:64 in layout string

Although i32 type is illegal in the backend, RV64I has pretty good support for i32 types by using W instructions.

By adding n32 to

[RISCV] Adjust RV64I data layout by using n32:64 in layout string

Although i32 type is illegal in the backend, RV64I has pretty good support for i32 types by using W instructions.

By adding n32 to the DataLayout string, middle end optimizations will consider i32 to be a native type. One known effect of this is enabling LoopStrengthReduce on loops with i32 induction variables. This can be beneficial because C/C++ code often has loops with i32 induction variables due to the use of `int` or `unsigned int`.

If this patch exposes performance issues, those are better addressed by tuning LSR or other passes.

Reviewed By: asb, frasercrmck

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

show more ...

[clang][RISCV] Set vscale_range attribute based on presence of "v" extension

This follows the path that AArch64 SVE has taken. Doing this via a function attribute set in the frontend is basically a

[clang][RISCV] Set vscale_range attribute based on presence of "v" extension

This follows the path that AArch64 SVE has taken. Doing this via a function attribute set in the frontend is basically a workaround for the fact that several analyzes which need the information (i.e. known bits, lvi, scev) can't easily use TTI without significant amounts of plumbing changes.

This patch hard codes "v" numbers, and directly follows the SVE precedent as a result. In a follow up, I hope to drive this from RISCVISAInfo.h/cpp instead, but the MinVLen number being returned from that interface seemed to always be 0 (which is wrong), and I haven't figured out what's going wrong there.

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

show more ...

[RISCV] Move isValidCPUName to RISCVTargetInfo. NFC

Instead of having separate implementations for RV32 and RV64,
use the triple to control the Is64Bit parameter.

Do the same for isValidTuneCPUName

[RISCV] Move isValidCPUName to RISCVTargetInfo. NFC

Instead of having separate implementations for RV32 and RV64,
use the triple to control the Is64Bit parameter.

Do the same for isValidTuneCPUName, fillValidCPUList, and
fillValidTuneCPUList.

show more ...

[RISCV] Fix int16 -> __fp16 conversion code gen

clang emit wrong code sequence for `int16`(`short`) to `__fp16` conversion,
and that should fix the code gen directly is the right way I think,
but I

[RISCV] Fix int16 -> __fp16 conversion code gen

clang emit wrong code sequence for `int16`(`short`) to `__fp16` conversion,
and that should fix the code gen directly is the right way I think,
but I found there is a FIXME comment in clang/Basic/TargetInfo.h say
that's should be removed in future so I think just let swich to using
generic LLVM IR rather than llvm.convert.to.fp16 intrinsics code gen
path is enough.

```
/// Check whether llvm intrinsics such as llvm.convert.to.fp16 should be used
/// to convert to and from __fp16.
/// FIXME: This function should be removed once all targets stop using the
/// conversion intrinsics.
virtual bool useFP16ConversionIntrinsics() const {
return true;
}
```

Reviewed By: craig.topper

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

show more ...

Introduce _BitInt, deprecate _ExtInt

WG14 adopted the _ExtInt feature from Clang for C23, but renamed the
type to be _BitInt. This patch does the vast majority of the work to
rename _ExtInt to _BitI

Introduce _BitInt, deprecate _ExtInt

WG14 adopted the _ExtInt feature from Clang for C23, but renamed the
type to be _BitInt. This patch does the vast majority of the work to
rename _ExtInt to _BitInt, which accounts for most of its size. The new
type is exposed in older C modes and all C++ modes as a conforming
extension. However, there are functional changes worth calling out:

* Deprecates _ExtInt with a fix-it to help users migrate to _BitInt.
* Updates the mangling for the type.
* Updates the documentation and adds a release note to warn users what
is going on.
* Adds new diagnostics for use of _BitInt to call out when it's used as
a Clang extension or as a pre-C23 compatibility concern.
* Adds new tests for the new diagnostic behaviors.

I want to call out the ABI break specifically. We do not believe that
this break will cause a significant imposition for early adopters of
the feature, and so this is being done as a full break. If it turns out
there are critical uses where recompilation is not an option for some
reason, we can consider using ABI tags to ease the transition.

show more ...

[RISCV] Unify the arch string parsing logic to to RISCVISAInfo.

How many place you need to modify when implementing a new extension for RISC-V?

At least 7 places as I know:

- Add new SubtargetFeat

[RISCV] Unify the arch string parsing logic to to RISCVISAInfo.

How many place you need to modify when implementing a new extension for RISC-V?

At least 7 places as I know:

- Add new SubtargetFeature at RISCV.td
- -march parser in RISCV.cpp
- RISCVTargetInfo::initFeatureMap@RISCV.cpp for handling feature vector.
- RISCVTargetInfo::getTargetDefines@RISCV.cpp for pre-define marco.
- Arch string parser for ELF attribute in RISCVAsmParser.cpp
- ELF attribute emittion in RISCVAsmParser.cpp, and make sure it's in
canonical order...
- ELF attribute emittion in RISCVTargetStreamer.cpp, and again, must in
canonical order...

And now, this patch provide an unified infrastructure for handling (almost)
everything of RISC-V arch string.

After this patch, you only need to update 2 places for implement an extension
for RISC-V:
- Add new SubtargetFeature at RISCV.td, hmmm, it's hard to avoid.
- Add new entry to RISCVSupportedExtension@RISCVISAInfo.cpp or
SupportedExperimentalExtensions@RISCVISAInfo.cpp .

Most codes are come from existing -march parser, but with few new feature/bug
fixes:
- Accept version for -march, e.g. -march=rv32i2p0.
- Reject version info with `p` but without minor version number like `rv32i2p`.

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

show more ...

[RISCV] Remove experimental-b extension that includes all Zb* extensions

At this point it looks like a B extension will never exist. Instead
Zba, Zbb, Zbc, and Zbs are individual extensions being ra

[RISCV] Remove experimental-b extension that includes all Zb* extensions

At this point it looks like a B extension will never exist. Instead
Zba, Zbb, Zbc, and Zbs are individual extensions being ratified
together as a package. Unknown at this time when or if the other
Zb* extensions will be ratified.

This patch removes references to the B extension. I've updated and
split tests accordingly.

This has been split from D110669 to make review a little easier.

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

show more ...

[RISCV] Remove Zbproposedc extension

This consists of 3 compressed instructions, c.not, c.neg, and c.zext.w.
I believe these have been picked up by the Zce effort using different
encodings. I don't

[RISCV] Remove Zbproposedc extension

This consists of 3 compressed instructions, c.not, c.neg, and c.zext.w.
I believe these have been picked up by the Zce effort using different
encodings. I don't think it makes sense to keep them in bitmanip. It
will eventually cause a conflict if/when Zce is implemented in llvm.

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

show more ...

[Clang][RISCV] Implement getConstraintRegister for RISC-V

The getConstraintRegister method is used by semantic checking of inline
assembly statements in order to diagnose conflicts between clobber l

[Clang][RISCV] Implement getConstraintRegister for RISC-V

The getConstraintRegister method is used by semantic checking of inline
assembly statements in order to diagnose conflicts between clobber list
and input/output lists. By overriding getConstraintRegister we get those
diagnostics and we match RISC-V GCC's behavior. The implementation is
trivial due to the lack of single-register RISC-V-specific constraints.

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

show more ...

[Clang][RISCV] Support half-precision floating point for RVV intrinsics.

Use _Float16 as the half-precision floating point type. Define a new
type specifier 'x' for the _Float16 type.

Differential

[Clang][RISCV] Support half-precision floating point for RVV intrinsics.

Use _Float16 as the half-precision floating point type. Define a new
type specifier 'x' for the _Float16 type.

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

show more ...

[RISCV] Prevent __builtin_riscv_orc_b_64 from being compiled RV32 target.

The backend can't handle this and will throw a fatal error from
type legalization. It's easy enough to fix that for this int

[RISCV] Prevent __builtin_riscv_orc_b_64 from being compiled RV32 target.

The backend can't handle this and will throw a fatal error from
type legalization. It's easy enough to fix that for this intrinsic
by just splitting the IR intrinsic since it works on individual bytes.

There will be other intrinsics in the future that would be harder
to support through splitting, for example grev, gorc, and shfl. Those
would require a compare and a select be inserted to check the MSB of
their control input.

This patch adds support for preventing this in the frontend with
a nice diagnostic.

Reviewed By: frasercrmck

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

show more ...

[RISCV] Add inline asm constraint 'vr' and 'vm' in Clang for RISC-V 'V'.

Add asm constraint 'vr' for vector registers.
Add asm constraint 'vm' for vector mask registers.

Differential Revision: http

[RISCV] Add inline asm constraint 'vr' and 'vm' in Clang for RISC-V 'V'.

Add asm constraint 'vr' for vector registers.
Add asm constraint 'vm' for vector mask registers.

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

show more ...

[RISCV] Fix mcount name

GCC's name for this symbol is _mcount, which the Linux kernel expects in
a few different place:

$ echo 'int main(void) { return 0; }' | riscv32-linux-gcc -c -pg -o tmp.o -

[RISCV] Fix mcount name

GCC's name for this symbol is _mcount, which the Linux kernel expects in
a few different place:

$ echo 'int main(void) { return 0; }' | riscv32-linux-gcc -c -pg -o tmp.o -x c -

$ llvm-objdump -dr tmp.o | grep mcount
0000000c: R_RISCV_CALL _mcount

$ echo 'int main(void) { return 0; }' | riscv64-linux-gcc -c -pg -o tmp.o -x c -

$ llvm-objdump -dr tmp.o | grep mcount
000000000000000c: R_RISCV_CALL _mcount

$ echo 'int main(void) { return 0; }' | clang -c -pg -o tmp.o --target=riscv32-linux-gnu -x c -

$ llvm-objdump -dr tmp.o | grep mcount
0000000a: R_RISCV_CALL_PLT mcount

$ echo 'int main(void) { return 0; }' | clang -c -pg -o tmp.o --target=riscv64-linux-gnu -x c -

$ llvm-objdump -dr tmp.o | grep mcount
000000000000000a: R_RISCV_CALL_PLT mcount

Set MCountName to "_mcount" in RISCVTargetInfo then prevent it from
getting overridden in certain OSTargetInfo constructors.

Reviewed By: MaskRay

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

Signed-off-by: Nathan Chancellor <nathan@kernel.org>

show more ...

[RISCV] Add vadd with mask and without mask builtin.

Demonstrate how to add RISC-V V builtins and lower them to IR intrinsics for V extension.

Authored-by: Roger Ferrer Ibanez <rofirrim@gmail.com>

[RISCV] Add vadd with mask and without mask builtin.

Demonstrate how to add RISC-V V builtins and lower them to IR intrinsics for V extension.

Authored-by: Roger Ferrer Ibanez <rofirrim@gmail.com>
Co-Authored-by: Hsiangkai Wang <kai.wang@sifive.com>

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

show more ...

[Clang][RISCV] Define RISC-V V builtin types

Add the types for the RISC-V V extension builtins.

These types will be used by the RISC-V V intrinsics which require
types of the form <vscale x 1 x i64

[Clang][RISCV] Define RISC-V V builtin types

Add the types for the RISC-V V extension builtins.

These types will be used by the RISC-V V intrinsics which require
types of the form <vscale x 1 x i64>(LMUL=1 element size=64) or
<vscale x 4 x i32>(LMUL=2 element size=32), etc. The vector_size
attribute does not work for us as it doesn't create a scalable
vector type. We want these types to be opaque and have no operators
defined for them. We want them to be sizeless. This makes them
similar to the ARM SVE builtin types. But we will have quite a bit
more types. This patch adds around 60. Later patches will add
another 230 or so types representing tuples of these types similar
to the x2/x3/x4 types in ARM SVE. But with extra complexity that
these types are combined with the LMUL concept that is unique to
RISCV.

For more background see this RFC
http://lists.llvm.org/pipermail/llvm-dev/2020-October/145850.html

Authored-by: Roger Ferrer Ibanez <roger.ferrer@bsc.es>
Co-Authored-by: Hsiangkai Wang <kai.wang@sifive.com>

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

show more ...

[RISCV] Implement new architecture extension macros

This adds support for the new architecture extension test macros as
defined in the C-API Document:
https://github.com/riscv/riscv-c-api-doc/blob/m

[RISCV] Implement new architecture extension macros

This adds support for the new architecture extension test macros as
defined in the C-API Document:
https://github.com/riscv/riscv-c-api-doc/blob/master/riscv-c-api.md

Extension versions have been taken from what are used in
RISCVTargetStreamer for ratified extensions, and the -march parser
for experimental extensions.

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

show more ...

[RISCV] Use default member initializers for the feature flags in RISCVTargetInfo. NFC

This avoids having to repeat all the flags in the constructor's
initializer list in the same order. This style i

[RISCV] Use default member initializers for the feature flags in RISCVTargetInfo. NFC

This avoids having to repeat all the flags in the constructor's
initializer list in the same order. This style is already used by
several other targets.

show more ...

[RISCV] Define preprocessor definitions for 'V' extension.

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

[RISCV] Handle zfh in the arch string.

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

[RISCV] Add -mtune support

- The goal of this patch is improve option compatible with RISCV-V GCC,
-mcpu support on GCC side will sent patch in next few days.

- -mtune only affect the pipeline

[RISCV] Add -mtune support

- The goal of this patch is improve option compatible with RISCV-V GCC,
-mcpu support on GCC side will sent patch in next few days.

- -mtune only affect the pipeline model and non-arch/extension related
target feature, e.g. instruction fusion; in td file it called
TuneFeatures, which is introduced by X86 back-end[1].

- -mtune accept all valid option for -mcpu and extra alias processor
option, e.g. `generic`, `rocket` and `sifive-7-series`, the purpose is
option compatible with RISCV-V GCC.

- Processor alias for -mtune will resolve according the current target arch,
rv32 or rv64, e.g. `rocket` will resolve to `rocket-rv32` or `rocket-rv64`.

- Interaction between -mcpu and -mtune:
* -mtune has higher priority than -mcpu for pipeline model and
TuneFeatures.

[1] https://reviews.llvm.org/D85165

Reviewed By: luismarques

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

show more ...

[RISCV] Add support for -mcpu option.

Summary:
1. gcc uses `-march` and `-mtune` flag to chose arch and
pipeline model, but clang does not have `-mtune` flag,
we uses `-mcpu` to chose both infos.
2.

[RISCV] Add support for -mcpu option.

Summary:
1. gcc uses `-march` and `-mtune` flag to chose arch and
pipeline model, but clang does not have `-mtune` flag,
we uses `-mcpu` to chose both infos.
2. Add SiFive e31 and u54 cpu which have default march
and pipeline model.
3. Specific `-mcpu` with rocket-rv[32|64] would select
pipeline model only, and use the driver's arch choosing
logic to get default arch.

Reviewers: lenary, asb, evandro, HsiangKai

Reviewed By: lenary, asb, evandro

Tags: #llvm, #clang

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

show more ...

Implement _ExtInt ABI for all ABIs in Clang, enable type for ABIs

This is the result of an audit of all of the ABIs in clang to implement
and enable the type for those targets.

Additionally, this f

Implement _ExtInt ABI for all ABIs in Clang, enable type for ABIs

This is the result of an audit of all of the ABIs in clang to implement
and enable the type for those targets.

Additionally, this finds an issue with integer-promotion passing for a
few platforms when using _ExtInt of < int, so this also corrects that
resulting in signext/zeroext being on a params of those types in some
platforms.

Differential Revisions: https://reviews.llvm.org/D79118

show more ...