[RISCV] Lazily add RVV C intrinsics.

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

[RISCV] Lazily add RVV C intrinsics.

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 <[email protected]>
Co-Authored-by: Hsiangkai Wang <[email protected]>

Reviewed By: khchen, aaron.ballman

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

show more ...

[AST][clangd] Expose documentation of Attrs on hover.

This adds a method to Attr to get at the documentation programmatically.

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

[OpenCL] Add OpenCL builtin test generator

Add a new clang-tblgen flag `-gen-clang-opencl-builtin-tests` that
generates a .cl file containing calls to every builtin function
defined in the .td input

[OpenCL] Add OpenCL builtin test generator

Add a new clang-tblgen flag `-gen-clang-opencl-builtin-tests` that
generates a .cl file containing calls to every builtin function
defined in the .td input.

This patch does not add any use of the new flag yet, so the only way
to obtain a generated test file is through a manual invocation of
clang-tblgen. A test making use of this emitter will be added in a
followup commit.

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

show more ...

[RISCV][Clang] Update new overloading rules for RVV intrinsics.

RVV intrinsics has new overloading rule, please see
https://github.com/riscv/rvv-intrinsic-doc/commit/82aac7dad4c6c1c351ed5b17ca6007c3

[RISCV][Clang] Update new overloading rules for RVV intrinsics.

RVV intrinsics has new overloading rule, please see
https://github.com/riscv/rvv-intrinsic-doc/commit/82aac7dad4c6c1c351ed5b17ca6007c395843ed7

Changed:
1. Rename `generic` to `overloaded` because the new rule is not using C11 generic.
2. Change HasGeneric to HasNoMaskedOverloaded because all masked operations
support overloading api.
3. Add more overloaded tests due to overloading rule changed.

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

show more ...

[Clang][RISCV] Add custom TableGen backend for riscv-vector intrinsics.

Demonstrate how to generate vadd/vfadd intrinsic functions

1. add -gen-riscv-vector-builtins for clang builtins.
2. add -gen-

[Clang][RISCV] Add custom TableGen backend for riscv-vector intrinsics.

Demonstrate how to generate vadd/vfadd intrinsic functions

1. add -gen-riscv-vector-builtins for clang builtins.
2. add -gen-riscv-vector-builtin-codegen for clang codegen.
3. add -gen-riscv-vector-header for riscv_vector.h. It also generates
ifdef directives with extension checking, base on D94403.
4. add -gen-riscv-vector-generic-header for riscv_vector_generic.h.
Generate overloading version Header for generic api.
https://github.com/riscv/rvv-intrinsic-doc/blob/master/rvv-intrinsic-rfc.md#c11-generic-interface
5. update tblgen doc for riscv related options.

riscv_vector.td also defines some unused type transformers for vadd,
because I think it could demonstrate how tranfer type work and we need
them for the whole intrinsic functions implementation in the future.

Authored-by: Roger Ferrer Ibanez <[email protected]>
Co-Authored-by: Zakk Chen <[email protected]>

Reviewed By: jrtc27, craig.topper, HsiangKai, Jim, Paul-C-Anagnostopoulos

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

show more ...

[Syntax] Start to move trivial Node class definitions to TableGen. NFC

This defines two node archetypes with trivial class definitions:
- Alternatives: the generated abstract classes are trivial as

[Syntax] Start to move trivial Node class definitions to TableGen. NFC

This defines two node archetypes with trivial class definitions:
- Alternatives: the generated abstract classes are trivial as all
functionality is via LLVM RTTI
- Unconstrained: this is a placeholder, I think all of these are going to be
Lists but today they have no special accessors etc, so we just say
"could contain anything", and migrate them one-by-one to Sequence later.

Compared to Dmitri's prototype, Nodes.td looks more like a class hierarchy and
less like a grammar. (E.g. variants list the Alternatives parent rather than
vice versa).
The main reasons for this:
- the hierarchy is an important part of the API we want direct control over.
- e.g. we may introduce abstract bases like "loop" that the grammar doesn't
care about in order to model is-a concepts that might make refactorings
more expressive. This is less natural in a grammar-like idiom.
- e.g. we're likely to have to model some alternatives as variants and others
as class hierarchies, the choice will probably be based on natural is-a
relationships.
- it reduces the cognitive load of switching from editing *.td to working with
code that uses the generated classes

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

show more ...

Reland [Syntax] Add minimal TableGen for syntax nodes. NFC

This reverts commit 09c6259d6d0eb51b282f6c3a28052a8146bc095b.
(Fixed side-effecting code being buried in an assert)

Revert "[Syntax] Add minimal TableGen for syntax nodes. NFC"

This reverts commit 55120f74ca12faea0e90fe552c85c14485f1fd91.

Segfaults during build:
http://lab.llvm.org:8011/#/builders/36/builds/1310

[Syntax] Add minimal TableGen for syntax nodes. NFC

So far, only used to generate Kind and implement classof().

My plan is to have this general-purpose Nodes.inc in the style of AST
DeclNodes.inc e

[Syntax] Add minimal TableGen for syntax nodes. NFC

So far, only used to generate Kind and implement classof().

My plan is to have this general-purpose Nodes.inc in the style of AST
DeclNodes.inc etc, and additionally a special-purpose backend generating
the actual class definitions. But baby steps...

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

show more ...

[clang][BFloat] add NEON emitter for bfloat

Summary:
This patch adds the bfloat16_t struct typedefs (e.g. bfloat16x8x2_t) to
arm_neon.h

This patch is part of a series implementing the Bfloat16 exte

[clang][BFloat] add NEON emitter for bfloat

Summary:
This patch adds the bfloat16_t struct typedefs (e.g. bfloat16x8x2_t) to
arm_neon.h

This patch is part of a series implementing the Bfloat16 extension of the
Armv8.6-a architecture, as detailed here:

https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a

The bfloat type, and its properties are specified in the Arm Architecture
Reference Manual:

https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile

The following people contributed to this patch:
- Luke Cheeseman
- Simon Tatham
- Ties Stuij

Reviewers: t.p.northover, fpetrogalli, sdesmalen, az, LukeGeeson

Reviewed By: fpetrogalli

Subscribers: SjoerdMeijer, LukeGeeson, pbarrio, mgorny, kristof.beyls, ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits

Tags: #clang

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

show more ...

[SveEmitter] Add range checks for immediates and predicate patterns.

Summary:
This patch adds a mechanism to easily add range checks for a builtin's
immediate operands. This patch is tested with the

[SveEmitter] Add range checks for immediates and predicate patterns.

Summary:
This patch adds a mechanism to easily add range checks for a builtin's
immediate operands. This patch is tested with the qdech intrinsic, which takes
both an enum for the predicate pattern, as well as an immediate for the
multiplier.

Reviewers: efriedma, SjoerdMeijer, rovka

Reviewed By: efriedma, SjoerdMeijer

Subscribers: mgorny, tschuett, mgrang, cfe-commits

Tags: #clang

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

show more ...

Reland D75470 [SVE] Auto-generate builtins and header for svld1.

Reworked the patch to avoid sharing a header (SVETypeFlags.h) between
include/clang/Basic and utils/TableGen/SveEmitter.cpp. Now the

Reland D75470 [SVE] Auto-generate builtins and header for svld1.

Reworked the patch to avoid sharing a header (SVETypeFlags.h) between
include/clang/Basic and utils/TableGen/SveEmitter.cpp. Now the patch
generates the enum/flags which is included in TargetBuiltins.h.

Also renamed one of the SveEmitter options to be in line with MVE.

Summary:

This is a first patch in a series for the SveEmitter to generate the arm_sve.h
header file and builtins.

I've tried my best to strip down this patch as best as I could, but there
are still a few changes that are not necessarily exercised by the load intrinsics
in this patch, mostly around the SVEType class which has some common logic to
represent types from a type and prototype string. I thought it didn't make
much sense to remove that from this patch and split it up.

show more ...

Revert "[SVE] Auto-generate builtins and header for svld1."

This reverts commit 8b409eabaf755c88a7d652fe99d3ad858a4fe82a.

Reverting this patch for now because it breaks some buildbots.

[SVE] Auto-generate builtins and header for svld1.

This is a first patch in a series for the SveEmitter to generate the arm_sve.h
header file and builtins.

I've tried my best to strip down this pat

[SVE] Auto-generate builtins and header for svld1.

This is a first patch in a series for the SveEmitter to generate the arm_sve.h
header file and builtins.

I've tried my best to strip down this patch as best as I could, but there
are still a few changes that are not necessarily exercised by the load intrinsics
in this patch, mostly around the SVEType class which has some common logic to
represent types from a type and prototype string. I thought it didn't make
much sense to remove that from this patch and split it up.

Reviewers: efriedma, rovka, SjoerdMeijer, rsandifo-arm, rengolin

Reviewed By: SjoerdMeijer

Tags: #clang

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

show more ...

[Clang][SVE] Parse builtin type string for scalable vectors

This patch adds 'q' to mean 'scalable vector' in the builtin
type string, and for SVE will return the matching builtin
type as defined in

[Clang][SVE] Parse builtin type string for scalable vectors

This patch adds 'q' to mean 'scalable vector' in the builtin
type string, and for SVE will return the matching builtin
type as defined in the C/C++ language extensions for SVE.

This patch also adds some scaffolding to generate the arm_sve.h
header file, and some builtin definitions (+CodeGen) to be able
to implement some simple masked load intrinsics that use the
ACLE types, such as:

svint8_t test_svld1_s8(svbool_t pg, const int8_t *base) {
return svld1_s8(pg, base);
}

Reviewers: efriedma, rjmccall, rovka, rsandifo-arm, rengolin

Reviewed By: efriedma

Tags: #clang

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

show more ...

[ARM,CDE] Generalize MVE intrinsics infrastructure to support CDE

Summary:
This patch generalizes the existing code to support CDE intrinsics
which will share some properties with existing MVE intri

[ARM,CDE] Generalize MVE intrinsics infrastructure to support CDE

Summary:
This patch generalizes the existing code to support CDE intrinsics
which will share some properties with existing MVE intrinsics
(some of the intrinsics will be polymorphic and accept/return values
of MVE vector types).
Specifically the patch:
* Adds new tablegen backends -gen-arm-cde-builtin-def,
-gen-arm-cde-builtin-codegen, -gen-arm-cde-builtin-sema,
-gen-arm-cde-builtin-aliases, -gen-arm-cde-builtin-header based on
existing MVE backends.
* Renames the '__clang_arm_mve_alias' attribute into
'__clang_arm_builtin_alias' (it will be used with CDE intrinsics as
well as MVE intrinsics)
* Implements semantic checks for the coprocessor argument of the CDE
intrinsics as well as the existing coprocessor intrinsics.
* Adds one CDE intrinsic __arm_cx1 to test the above changes

Reviewers: simon_tatham, MarkMurrayARM, ostannard, dmgreen

Reviewed By: simon_tatham

Subscribers: sdesmalen, mgorny, kristof.beyls, danielkiss, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

show more ...

Abstract serialization: TableGen the (de)serialization code for Types.

The basic technical design here is that we have three levels
of readers and writers:

- At the lowest level, there's a `Basic{R

Abstract serialization: TableGen the (de)serialization code for Types.

The basic technical design here is that we have three levels
of readers and writers:

- At the lowest level, there's a `Basic{Reader,Writer}` that knows
how to emit the basic structures of the AST. CRTP allows this to
be metaprogrammed so that the client only needs to support a handful
of primitive types (e.g. `uint64_t` and `IdentifierInfo*`) and more
complicated "inline" structures such as `DeclarationName` can just
be emitted in terms of those primitives.

In Clang's binary-serialization code, these are
`ASTRecord{Reader,Writer}`. For now, a large number of basic
structures are still emitted explicitly by code on those classes
rather than by either TableGen or CRTP metaprogramming, but I
expect to move more of these over.

- In the middle, there's a `Property{Reader,Writer}` which is
responsible for processing the properties of a larger object. The
object-level reader/writer asks the property-level reader/writer to
project out a particular property, yielding a basic reader/writer
which will be used to read/write the property's value, like so:

```
propertyWriter.find("count").writeUInt32(node->getCount());
```

Clang's binary-serialization code ignores this level (it uses
the basic reader/writer as the property reader/writer and has the
projection methods just return `*this`) and simply relies on the
roperties being read/written in a stable order.

- At the highest level, there's an object reader/writer (e.g.
`Type{Reader,Writer}` which emits a logical object with properties.
Think of this as writing something like a JSON dictionary literal.

I haven't introduced support for bitcode abbreviations yet --- it
turns out that there aren't any operative abbreviations for types
besides the QualType one --- but I do have some ideas of how they
should work. At any rate, they'll be necessary in order to handle
statements.

I'm sorry for not disentangling the patches that added basic and type
reader/writers; I made some effort to, but I ran out of energy after
disentangling a number of other patches from the work.

Negligible impact on module size, time to build a set of about 20
fairly large modules, or time to read a few declarations out of them.

show more ...

Abstract serialization: TableGen "basic" reader/writer CRTP
classes that serialize basic values

[NFC] Rename ClangASTEmitters.h -> ASTTableGen.h

Revert "Use InitLLVM to setup a pretty stack printer"

This reverts commit 3f76260dc0674cc0acb25f550a0f0c594cf537ea.
Breaks at least these tests on Windows:
Clang :: Driver/clang-offload-bundler.

Revert "Use InitLLVM to setup a pretty stack printer"

This reverts commit 3f76260dc0674cc0acb25f550a0f0c594cf537ea.
Breaks at least these tests on Windows:
Clang :: Driver/clang-offload-bundler.c
Clang :: Driver/clang-offload-wrapper.c

show more ...

Use InitLLVM to setup a pretty stack printer

InitLLVM does not only save a few lines from main() but also makes the
commands do the right thing for multibyte character pathnames on
Windows (i.e. can

Use InitLLVM to setup a pretty stack printer

InitLLVM does not only save a few lines from main() but also makes the
commands do the right thing for multibyte character pathnames on
Windows (i.e. canonicalize argv's to UTF-8) because of the code we
have in this file:

https://github.com/llvm/llvm-project/blob/master/llvm/lib/Support/InitLLVM.cpp#L32

For many LLVM commands, we already have calls of InitLLVM, but there
are still remainings.

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

show more ...

[NFC] Add a tablegen node for the root of the AST node hierarchies.

This is useful for the property databases we want to add for abstract
serialization, since root classes can have interesting prope

[NFC] Add a tablegen node for the root of the AST node hierarchies.

This is useful for the property databases we want to add for abstract
serialization, since root classes can have interesting properties.

show more ...

[clang,ARM] Initial ACLE intrinsics for MVE.

This commit sets up the infrastructure for auto-generating <arm_mve.h>
and doing clang-side code generation for the builtins it relies on,
and demonstrat

[clang,ARM] Initial ACLE intrinsics for MVE.

This commit sets up the infrastructure for auto-generating <arm_mve.h>
and doing clang-side code generation for the builtins it relies on,
and demonstrates that it works by implementing a representative sample
of the ACLE intrinsics, more or less matching the ones introduced in
LLVM IR by D67158,D68699,D68700.

Like NEON, that header file will provide a set of vector types like
uint16x8_t and C functions with names like vaddq_u32(). Unlike NEON,
the ACLE spec for <arm_mve.h> includes a polymorphism system, so that
you can write plain vaddq() and disambiguate by the vector types you
pass to it.

Unlike the corresponding NEON code, I've arranged to make every user-
facing ACLE intrinsic into a clang builtin, and implement all the code
generation inside clang. So <arm_mve.h> itself contains nothing but
typedefs and function declarations, with the latter all using the new
`__attribute__((__clang_builtin))` system to arrange that the user-
facing function names correspond to the right internal BuiltinIDs.

So the new MveEmitter tablegen system specifies the full sequence of
IRBuilder operations that each user-facing ACLE intrinsic should
translate into. Where possible, the ACLE intrinsics map to standard IR
operations such as vector-typed `add` and `fadd`; where no standard
representation exists, I call down to the sample IR intrinsics
introduced in an earlier commit.

Doing it like this means that you get the polymorphism for free just
by using __attribute__((overloadable)): the clang overload resolution
decides which function declaration is the relevant one, and _then_ its
BuiltinID is looked up, so by the time we're doing code generation,
that's all been resolved by the standard system. It also means that
you get really nice error messages if the user passes the wrong
combination of types: clang will show the declarations from the header
file and explain why each one doesn't match.

(The obvious alternative approach would be to have wrapper functions
in <arm_mve.h> which pass their arguments to the underlying builtins.
But that doesn't work in the case where one of the arguments has to be
a constant integer: the wrapper function can't pass the constantness
through. So you'd have to do that case using a macro instead, and then
use C11 `_Generic` to handle the polymorphism. Then you have to add
horrible workarounds because `_Generic` requires even the untaken
branches to type-check successfully, and //then// if the user gets the
types wrong, the error message is totally unreadable!)

Reviewers: dmgreen, miyuki, ostannard

Subscribers: mgorny, javed.absar, kristof.beyls, cfe-commits

Tags: #clang

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

show more ...

Emit TypeNodes.def with tblgen.

The primary goal here is to make the type node hierarchy available to
other tblgen backends, although it should also make it easier to generate
more selective x-macro

Emit TypeNodes.def with tblgen.

The primary goal here is to make the type node hierarchy available to
other tblgen backends, although it should also make it easier to generate
more selective x-macros in the future.

Because tblgen doesn't seem to allow backends to preserve the source
order of defs, this is not NFC because it significantly re-orders IDs.
I've fixed the one (fortunately obvious) place where we relied on
the old order. Unfortunately, I wasn't able to share code with the
existing AST-node x-macro generators because the x-macro schema we use
for types is different in a number of ways. The main loss is that
subclasses aren't ordered together, which doesn't seem important for
types because the hierarchy is generally very shallow with little
clustering.

llvm-svn: 373407

show more ...

[Clang Interpreter] Initial patch for the constexpr interpreter

Summary:
This patch introduces the skeleton of the constexpr interpreter,
capable of evaluating a simple constexpr functions consistin

[Clang Interpreter] Initial patch for the constexpr interpreter

Summary:
This patch introduces the skeleton of the constexpr interpreter,
capable of evaluating a simple constexpr functions consisting of
if statements. The interpreter is described in more detail in the
RFC. Further patches will add more features.

Reviewers: Bigcheese, jfb, rsmith

Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits

Tags: #clang

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

llvm-svn: 371834

show more ...