This fixes some fallout from D131282. Currently, add_tablegen() will add the tablegen target to LLVM_EXPORTS and associates the install with LLVMExports. For non-standalone builds, this means that you end up with mlir-tblgen and clang-tblgen in LLVMExports.
However, these projects should instead be using MLIR_EXPORTS/MLIRTargets and CLANG_EXPORTS/ClangTargets. To fix this, add an extra EXPORT option and make use of get_target_export_arg() to create the correct export argument.
Reviewed By: ashay-github
Differential Revision: https://reviews.llvm.org/D131565
Adds
* `__add_lvalue_reference`
* `__add_pointer`
* `__add_rvalue_reference`
* `__decay`
* `__make_signed`
* `__make_unsigned`
* `__remove_all_extents`
* `__remove_extent`
* `__remove_const`
* `__remove_volatile`
* `__remove_cv`
* `__remove_pointer`
* `__remove_reference`
* `__remove_cvref`
These are all compiler built-in equivalents of the unary type traits
found in [[meta.trans]][1]. The compiler already has all of the
information it needs to answer these transformations, so we can skip
needing to make partial specialisations in standard library
implementations (we already do this for a lot of the query traits). This
will hopefully improve compile times, as we won't need use as much
memory in such a base part of the standard library.
[1]: http://wg21.link/meta.trans
Co-authored-by: zoecarver
Reviewed By: aaron.ballman, rsmith
Differential Revision: https://reviews.llvm.org/D116203
arm_sve.h defines and uses __ai macro which needs to be undefined (as it is
already in arm_neon.h).
Reviewed By: paulwalker-arm
Differential Revision: https://reviews.llvm.org/D131580
This encapsulates 3 changes:
- `DotDumpVisitor` now aggregates strings instead of *bytes* for both
`python2` and `python3`. This difference caused crashes when it tried
to write out the content as *strings*, similarly described at D71746.
- `graphviz.pipe()` expects the input in *bytes* instead of unicode
strings. And it results in *bytes*. Due to string concatenations and
similar operations, I'm using unicode string as the default, and
converting to *bytes* on demand.
- `write_temp_file()` now appends the `egraph-` prefix and more
importantly, it will create the temp file in the **current working
directory** instead of in the *temp*. This change makes `Firefox` be
able to open the file even if the `security.sandbox.content.level` is
set to the (default) most restricting `4`.
See https://support.mozilla.org/si/questions/1259285
An artifact of the bad byte handling was previously in the `HTML`
produced by the script that it displayed the `b'` string at the top left
corner. Now it won't anymore :)
I've tested that the following command works on `Ubuntu 22.04`:
```
exploded-graph-rewriter my-egraph.dot
```
Both `python2` and `python3` works as expected.
PS: I'm not adding tests, as the current test infra does not support
testing HTML outputs for this script.
Check the `clang/test/Analysis/exploded-graph-rewriter/lit.local.cfg`.
We always pass the `--dump-dot-only` flag to the script.
Along with that, the default invocation will not only create this HTML
report but also try to open it. In addition to this, I'm not sure if the
buildbots have `graphviz` installed and also if this package is installed
on `pip`.
Unless we change some of these, we cannot test this change.
Given that D71746 had no tests, I'm not too worried about this either.
Reviewed By: NoQ
Differential Revision: https://reviews.llvm.org/D131553
Prior to this patch, the `add_tablegen()` macro in
llvm/cmake/modules/TableGen.cmake added the install rule only if
`project` matched `LLVM` or `MLIR`. This patch adds an optional
`DESTINATION` argument, which, if non-empty, decides whether (and where)
to install the tablegen tool, thus eliminating the need for
project-specific overrides. This patch also updates all other
invocations of the `add_tablegen()` macro.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D131282
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
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
I went over the output of the following mess of a command:
(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z |
parallel --xargs -0 cat | aspell list --mode=none --ignore-case |
grep -E '^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n |
grep -vE '.{25}' | aspell pipe -W3 | grep : | cut -d' ' -f2 | less)
and proceeded to spend a few days looking at it to find probable typos
and fixed a few hundred of them in all of the llvm project (note, the
ones I found are not anywhere near all of them, but it seems like a
good start).
Differential Revision: https://reviews.llvm.org/D130827
The code relied on ManagedStatic.h being included indirectly. This is
about to change as uses of ManagedStatic are removed throughout the
codebase.
Differential Revision: https://reviews.llvm.org/D130575
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
This patch aims to create a webpage to document
Flang's command line options on https://flang.llvm.org/docs/
in a similar way to Clang's
https://clang.llvm.org/docs/ClangCommandLineReference.html
This is done by using clang_tablegen to generate an .rst
file from Options.td (which is current shared with Clang)
For this to work, ClangOptionDocEmitter.cpp was updated
to allow specific Flang flags to be included,
rather than bulk excluding clang flags.
Note:
Some headings in the generated documentation will incorrectly
contain references to Clang, e.g.
"Flags controlling the behaviour of Clang during compilation"
This is because Options.td (Which is shared between both Clang and Flang)
contains hard-coded DocBrief sections. I couldn't find a non-intrusive way
to make this target-dependant, as such I've left this as is, and it will need revisiting later.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D129864
This patch aims to create a webpage to document
Flang's command line options on https://flang.llvm.org/docs/
in a similar way to Clang's
https://clang.llvm.org/docs/ClangCommandLineReference.html
This is done by using clang_tablegen to generate an .rst
file from Options.td (which is current shared with Clang)
For this to work, ClangOptionDocEmitter.cpp was updated
to allow specific Flang flags to be included,
rather than bulk excluding clang flags.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D129864
Introducing the support for evaluating the constructor
of every element in an array. The idea is to record the
index of the current array member being constructed and
create a loop during the analysis. We looping over the
same CXXConstructExpr as many times as many elements
the array has.
Differential Revision: https://reviews.llvm.org/D127973
RVV C intrinsics use pointers to scalar for base address and their corresponding
IR intrinsics but use pointers to vector. It makes some vector load intrinsics
need specific ManualCodegen and MaskedManualCodegen to just add bitcast for
transforming to IR.
For simplifying riscv_vector.td, the patch make RISCVEmitter detect pointer
operands and bitcast them.
Reviewed By: kito-cheng
Differential Revision: https://reviews.llvm.org/D129043
Almost all attributes currently marked `Undocumented` are user-facing
attributes which _ought_ to be documented, but nobody has written it
yet. This change ensures that we at least acknowledge that these
attributes exist in the documentation, even if we have no description
of their semantics.
A new category, `InternalOnly` has been added for those few attributes
which are not user-facing, and should remain omitted from the docs.
For certain cases (such as for the double subtype of AGenType), the
OpenCLBuiltinFileEmitterBase would not emit the extension #if-guard.
Fix that by looking at the extension of the actual type instead of the
argument type (which could be a GenType that does not carry any
extension information).
Instead of assuming there is an HTML file for each diagnostics, consider
the HTML files only when they exist, individually of each other.
After generating the reference data, running
python /scripts/SATest.py build --projects simbody
was resulting in this error:
File "/scripts/CmpRuns.py", line 250, in read_single_file
assert len(d['HTMLDiagnostics_files']) == 1
KeyError: 'HTMLDiagnostics_files'
Reviewed By: steakhal
Differential Revision: https://reviews.llvm.org/D126197
Solve build issues occurring when running `docker build`.
Fix the version of cmake-data to solve the following issue:
The following packages have unmet dependencies:
cmake : Depends: cmake-data (= 3.20.5-0kitware1) but 3.23.1-0kitware1ubuntu18.04.1 is to be installed
Install libjpeg to solve this issue when installing Python
requirements:
The headers or library files could not be found for jpeg,
a required dependency when compiling Pillow from source.
Reviewed By: steakhal
Differential Revision: https://reviews.llvm.org/D126196
For backwards compatiblity, we emit only a warning instead of an error if the
attribute is one of the existing type attributes that we have historically
allowed to "slide" to the `DeclSpec` just as if it had been specified in GNU
syntax. (We will call these "legacy type attributes" below.)
The high-level changes that achieve this are:
- We introduce a new field `Declarator::DeclarationAttrs` (with appropriate
accessors) to store C++11 attributes occurring in the attribute-specifier-seq
at the beginning of a simple-declaration (and other similar declarations).
Previously, these attributes were placed on the `DeclSpec`, which made it
impossible to reconstruct later on whether the attributes had in fact been
placed on the decl-specifier-seq or ahead of the declaration.
- In the parser, we propgate declaration attributes and decl-specifier-seq
attributes separately until we can place them in
`Declarator::DeclarationAttrs` or `DeclSpec::Attrs`, respectively.
- In `ProcessDeclAttributes()`, in addition to processing declarator attributes,
we now also process the attributes from `Declarator::DeclarationAttrs` (except
if they are legacy type attributes).
- In `ConvertDeclSpecToType()`, in addition to processing `DeclSpec` attributes,
we also process any legacy type attributes that occur in
`Declarator::DeclarationAttrs` (and emit a warning).
- We make `ProcessDeclAttribute` emit an error if it sees any non-declaration
attributes in C++11 syntax, except in the following cases:
- If it is being called for attributes on a `DeclSpec` or `DeclaratorChunk`
- If the attribute is a legacy type attribute (in which case we only emit
a warning)
The standard justifies treating attributes at the beginning of a
simple-declaration and attributes after a declarator-id the same. Here are some
relevant parts of the standard:
- The attribute-specifier-seq at the beginning of a simple-declaration
"appertains to each of the entities declared by the declarators of the
init-declarator-list" (https://eel.is/c++draft/dcl.dcl#dcl.pre-3)
- "In the declaration for an entity, attributes appertaining to that entity can
appear at the start of the declaration and after the declarator-id for that
declaration." (https://eel.is/c++draft/dcl.dcl#dcl.pre-note-2)
- "The optional attribute-specifier-seq following a declarator-id appertains to
the entity that is declared."
(https://eel.is/c++draft/dcl.dcl#dcl.meaning.general-1)
The standard contains similar wording to that for a simple-declaration in other
similar types of declarations, for example:
- "The optional attribute-specifier-seq in a parameter-declaration appertains to
the parameter." (https://eel.is/c++draft/dcl.fct#3)
- "The optional attribute-specifier-seq in an exception-declaration appertains
to the parameter of the catch clause" (https://eel.is/c++draft/except.pre#1)
The new behavior is tested both on the newly added type attribute
`annotate_type`, for which we emit errors, and for the legacy type attribute
`address_space` (chosen somewhat randomly from the various legacy type
attributes), for which we emit warnings.
Depends On D111548
Reviewed By: aaron.ballman, rsmith
Differential Revision: https://reviews.llvm.org/D126061
Building on D126796, this commit adds the infrastructure for being able
to print out descriptions of what each warning does.
Differential Revision: https://reviews.llvm.org/D126832
Copy hmaptool using the paths for CURRENT_TOOLS_DIR, so
everything goes in the right place in case llvm is included
from a top level CMakeLists.txt.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: stephenneuendorffer
Differential Revision: https://reviews.llvm.org/D126308
As discussed on the review, this change breaks the standalone
clang build. When building against an installed LLVM, the
LLVM_TOOLS_BINARY_DIR cmake variable points to the location of
the installed LLVM tools, not to the cmake build directory. This
means that we would end up trying to move hmaptool into something
like /usr/bin as part of the normal build, while this should only
be happening when running an install target.
This reverts commit bf1ab1f0eb.
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
D126308 broke building clang standalone, as LLVM_UTILS_INSTALL_DIR is
not exported.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D126671
Install hmaptool using the LLVM specific variables, so
everything goes in the right place in case llvm is included
from a top level CMakeLists.txt.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: stephenneuendorffer
Differential Revision: https://reviews.llvm.org/D126308
- Use `Overloaded` rather than `Mangled`.
- Use `Prototype` or `Desc` rather than `Seq`, it's not just a string sequence.
- `Prototype` for those PrototypeDescriptor will used to evaluate as argument type.
- `Desc` for those PrototypeDescriptor will used to evaluate as part of function name.
Reviewed By: khchen
Differential Revision: https://reviews.llvm.org/D125886
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
Nikita Popov