Often we run into situations where we want to ignore
warnings from system headers, but Clang will still
give warnings about the contents of a macro defined
in a system header used in user-code.
Introduce a ShowInSystemMacro option to be able to
specify which warnings we do want to keep raising
warnings for. The current behavior is kept in this patch
(i.e. warnings from system macros are enabled by default).
The decision as to whether this should be an opt-in or opt-out
feature can be made in a separate patch.
To put the feature to test, replace duplicated code for
Wshadow and Wold-style-cast with the SuppressInSystemMacro tag.
Also disable the warning for C++20 designators, fixing #52944.
Differential Revision: https://reviews.llvm.org/D116833
This reverts commit 80e2c58749.
The original patch causes a lot of warnings on gcc like:
llvm-project/clang/include/clang/Basic/Diagnostic.h:1329:3: warning:
base class ‘class clang::StreamingDiagnostic’ should be explicitly
initialized in the copy constructor [-Wextra]
This adjusts all the MVE and CDE intrinsics now that v2i1 is a legal
type, to use a <2 x i1> as opposed to emulating the predicate with a
<4 x i1>. The v4i1 workarounds have been removed leaving the natural
v2i1 types, notably in vctp64 which now generates a v2i1 type.
AutoUpgrade code has been added to upgrade old IR, which needs to
convert the old v4i1 to a v2i1 be converting it back and forth to an
integer with arm.mve.v2i and arm.mve.i2v intrinsics. These should be
optimized away in the final assembly.
Differential Revision: https://reviews.llvm.org/D114455
This is just a few trivial changes -- change the interpreter and fix a
few byte-vs-string issues.
Differential Revision: https://reviews.llvm.org/D107944
[NFC] As part of using inclusive language within the llvm project and to
match the renamed master branch, this patch replaces master with main in
`convert_arm_neon.py`.
Reviewed By: kristof.beyls
Differential Revision: https://reviews.llvm.org/D113942
As for now, the categories are printed in an arbitrary order which
depends on the addresses of dynamically allocated objects. The patch
sorts them in an alphabetical order thus making the output stable.
Differential Revision: https://reviews.llvm.org/D113477
These should be all the commands from [1] except those that are marked
obsolete, and "link" / "endlink", as that conflicts with the existing
HeaderDoc pair "link / "/link". For some commands we don't have the
ideal category, but it should work good enough for most cases.
There seems to be no existing test for most commands (except the ones
interpreted by -Wdocumentation), and to some extent such a test wouldn't
look very interesting. But I added a test for the correct parsing of
formulas, as they're a bit special. And I had to adapt
comment-lots-of-unknown-commands.c because typo correction was kicking
in and recognizing some of the commands.
This should fix a couple of reported bugs: PR17437, PR19581, PR24062
(partially, no diagnostic for matching cond/endcond), PR32909, PR37813,
PR44243 (partially, email@domain.com must be addressed separately).
[1] https://www.doxygen.nl/manual/commands.html
Reviewed By: gribozavr2
Differential Revision: https://reviews.llvm.org/D111190
All but 2 of the vector builtins are only used by clang_builtin_alias.
When using clang_builtin_alias, the type string of the builtin is never
checked. Only the types in the function definition used for the alias
are checked.
This patch takes advantage of this to share a single builtin for
many different types. We already used type overloads on the IR intrinsic
so the codegen for the builtins that are being merge were already
the same. This extends the type overloading to the builtins.
I had to make a few tweaks to make this work.
-Floating point vector-vector vmerge now uses the vmerge intrinsic
instead of the vfmerge intrinsic. New isel patterns and tests are
added to support this.
-The SemaChecking for the immediate of vset_v/vget_v has been removed.
Determining the valid range is harder now. I've added masking to
ManualCodegen to ensure valid IR for invalid input.
This reduces the number of builtins from ~25000 to ~1100.
Reviewed By: HsiangKai
Differential Revision: https://reviews.llvm.org/D112102
This patch selects all cmake options and passes them to global cmake
command while building LLVM inside satest docker container.
Prior to this, the cmake command was hard-coded and this would consume
a huge amount of memory while building. There was no support to pass
extra cmake options for the build, except for changing the command
manually. This patch allows testers to pass all "-D*" cmake options to
the build.
Reviewed By: vsavchenko
Differential Revision: https://reviews.llvm.org/D105447
Patch by: @manas (Manas Gupta)
Zvamo is not part of the 1.0 V spec. Remove the intrinsics
for now. This helps reduce clang binary size and lit test time.
Reviewed By: HsiangKai
Differential Revision: https://reviews.llvm.org/D111692
Previously we used builtin_alias for overloaded intrinsics, but
macros for the non-overloaded version. This patch changes the
non-overloaded versions to also use builtin_alias, but without
the overloadable attribute.
Reviewed By: khchen, HsiangKai
Differential Revision: https://reviews.llvm.org/D112020
It was being used to control the nothrow attribute on the builtins. The
nothrow attribute is for C++ exceptions. Even if the vector builtins
have side effects in IR, that's different than the nothrow attribute.
Reviewed By: HsiangKai
Differential Revision: https://reviews.llvm.org/D112028
Similar to SVE, this separates the RVV builtlins into their own
region of builtin IDs. Only those IDs are allowed to be used by
the builtin_alias attribute now.
Reviewed By: HsiangKai
Differential Revision: https://reviews.llvm.org/D111923
The attributes string doesn't include 'f' or 'h'. I don't think
any code looks at the header name without those.
Reviewed By: simon_tatham
Differential Revision: https://reviews.llvm.org/D111755
This reverts commit 97f0c63783.
As discussed in https://reviews.llvm.org/D110684, it increased the
compile time and the binary size of clang more than 1%. I reverted
this patch first to think about a better way to do it.
In the original design, we levarage _mt intrinsics to define macros for
_m intrinsics. Such as,
```
__builtin_rvv_vadd_vv_i8m1_mt((vbool8_t)(op0), (vint8m1_t)(op1), (vint8m1_t)(op2), (vint8m1_t)(op3), (size_t)(op4), (size_t)VE_TAIL_AGNOSTIC)
```
However, we could not define generic interface for mask intrinsics any
more due to clang_builtin_alias only accepts clang builtins as its
argument.
In the example,
```
__rvv_overloaded
__attribute__((clang_builtin_alias(__builtin_rvv_vadd_vv_i8m1_mt)))
vint8m1_t vadd(vbool8_t op0, vint8m1_t op1, vint8m1_t op2, vint8m1_t
op3, size_t op4, size_t op5);
```
op5 is the tail policy argument. When users want to use vadd generic
interface for masked vector add, they need to specify tail policy in the
previous design. In this patch, we define _m intrinsics as clang
builtins to solve the problem.
Differential Revision: https://reviews.llvm.org/D110684
The IR intrinsics use ImmArg for the policy operand so this needs to be enforced as a constant in the frontend.
Differential Revision: https://reviews.llvm.org/D110779
It replaces the usage of readPlist,writePlist functions with load,dump
in plistlib package.
This fixes deprecation issues when analyzer reports are being generated
outside of docker.
Patch by Manas!
Reviewed By: steakhal
Differential Revision: https://reviews.llvm.org/D107312
clang-cl maps /wdNNNN to -Wno-flags for a few warnings that map
cleanly from cl.exe concepts to clang concepts.
This patch adds support for the same numbers to
`#pragma warning(disable : NNNN)`. It also lets
`#pragma warning(push)` and `#pragma warning(pop)` have an effect,
since these are used together with `warning(disable)`.
The optional numeric argument to `warning(push)` is ignored,
as are the other non-`disable` `pragma warning()` arguments.
(Supporting `error` would be easy, but we also don't support
`/we`, and those should probably be added together.)
The motivating example is that a bunch of code (including in LLVM)
uses this idiom to locally disable warnings about calls to deprecated
functions in Windows-only code, and 4996 maps nicely to
-Wno-deprecated-declarations:
#pragma warning(push)
#pragma warning(disable: 4996)
f();
#pragma warning(pop)
Implementation-wise:
- Move `/wd` flag handling from Options.td to actual Driver-level code
- Extract the function mapping cl.exe IDs to warning groups to the
new file clang/lib/Basic/CLWarnings.cpp
- Create a diag::Group enum so that CLWarnings.cpp can refer to
existing groups by ID (and give DllexportExplicitInstantiationDecl
a named group), and add a function to map a diag::Group to the
spelling of it's associated commandline flag
- Call that new function from PragmaWarningHandler
Differential Revision: https://reviews.llvm.org/D110668
Add the tail policy argument to Clang builtins. There
are two policies for tail elements. Tail agnostic means users do not
care about the values in the tail elements and tail undisturbed means
the values in the tail elements need to be kept after the operation. In
order to let users control the tail policy, we add an additional
argument at the end of the argument list.
For unmasked operations, we have no maskedoff and the tail policy is
always tail agnostic. If users want to keep tail elements under unmasked
operations, they could use all one mask in the masked operations to do
it. So, we only add the additional argument for masked operations for
most cases. There are exceptions listed below.
In this patch, we do not handle the following cases to reduce the
complexity of the patch. There could be two separate patches for them.
Use dest argument to control tail policy
vmerge.vvm/vmerge.vxm/vmerge.vim (add _t builtins with additional dest
argument)
vfmerge.vfm (add _t builtins with additional dest argument)
vmv.v.v (add _t builtins with additional dest argument)
vmv.v.x (add _t builtins with additional dest argument)
vmv.v.i (add _t builtins with additional dest argument)
vfmv.v.f (add _t builtins with additional dest argument)
vadc.vvm/vadc.vxm/vadc.vim (add _t builtins with additional dest
argument)
vsbc.vvm/vsbc.vxm (add _t builtins with additional dest argument)
Always has tail argument for masked/unmasked intrinsics
Vector Single-Width Integer Multiply-Add Instructions (add _t and _mt
builtins)
Vector Widening Integer Multiply-Add Instructions (add _t and _mt
builtins)
Vector Single-Width Floating-Point Fused Multiply-Add Instructions (add
_t and _mt builtins)
Vector Widening Floating-Point Fused Multiply-Add Instructions (add _t
and _mt builtins)
Vector Reduction Operations (add _t and _mt builtins)
Vector Slideup Instructions (add _t and _mt builtins)
Vector Slidedown Instructions (add _t and _mt builtins)
Discussion: https://github.com/riscv/rvv-intrinsic-doc/pull/101
Differential Revision: https://reviews.llvm.org/D109322
Completion now looks more like function/member completion:
used
alias(Aliasee)
abi_tag(Tags...)
Differential Revision: https://reviews.llvm.org/D108109
This patch adds the flag `extra-checkers` to the sub-command `build` for
passing a comma separated list of additional checkers to include.
Differential Revision: https://reviews.llvm.org/D106739
Also clang ClangAttrEmitter for -gen-clang-attr-doc-table to be
like all other tablegen: Produce a .inc file with the generated bits
and put the static parts into a regular .cpp file that includes the
.inc file.
The Clang interpreter's bytecode uses a packed stream of bytes
representation, but also wants to have some opcodes take pointers as
arguments, which are currently embedded in the bytecode directly.
However, CHERI, and thus Arm's upcoming experimental Morello prototype,
provide spatial memory safety for C/C++ by implementing language-level
(and sub-language-level) pointers as capabilities, which track bounds,
permissions and validity in hardware. This uses tagged memory with a
single tag bit at every capability-aligned address, and so storing
pointers to unaligned addresses results in the tag being stripped,
leading to a tag fault when the pointer is ultimately dereferenced at a
later point.
In order to support a stricter C/C++ implementation like CHERI, we no
longer store pointers directly in the bytecode, instead storing them in
a table and embedding the index in the bytecode.
Reviewed By: nand
Differential Revision: https://reviews.llvm.org/D97606
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
Since 8866793b4e ("[OpenCL] Add OpenCL builtin test generator",
2021-06-09) there are two emitters in this file, so move the
file-level comment to the appropriate class.
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
This reapplies commit 95033eb3 that reverted commit 1d9e8e13.
The tests were failing on Windows due to spaces and backslashes in paths not being handled carefully.
This patch adds support for inferred modules to the dependency scanner.
Effectively a cherry-pick of https://github.com/apple/llvm-project/pull/699 authored by @Bigcheese with libclang and other changes omitted.
Contains following changes:
1. [Clang][ScanDeps] Ignore __inferred_module.map dependency.
* This shows up with inferred modules, but it doesn't exist on disk, so don't report it as a dependency.
2. [Clang][ScanDeps] Use the module map a module was inferred from for inferred modules.
Also includes a smoke test that uses clang-scan-deps output to perform an explicit build. There's no intention to duplicate whatever `test/Modules` contains, just to verify the produced command-line does "work" (with very loose definition of work).
Split from D100934.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D102495
We have vector operations on double vector and float scalar. For
example, vfwadd.wf is such a instruction.
vfloat64m1_t vfwadd_wf(vfloat64m1_t op0, float op1, size_t op2);
We should specify F and D extensions for it.
Differential Revision: https://reviews.llvm.org/D102051
This patch makes the builtin operand order match the C operand order
for all intrinsics. With this we can use clang_builtin_alias for
all overloaded intrinsics.
This should further reduce the test time for vector intrinsics.
Differential Revision: https://reviews.llvm.org/D101700
We only apply `clang_builtin_alias` to non-masked builtins.
Masked builtins could not use `clang_builtin_alias` because the
operand order is different between overloaded intrinsics and builtins.
A bunch of test cases need to be updated.
Differential Revision: https://reviews.llvm.org/D100658
Add functionality to assign extensions to types in OpenCLBuiltins.td
and use that information to filter candidates that should not be
exposed if a type is not available.
Differential Revision: https://reviews.llvm.org/D100209
Instead of using a MinVersion and MaxVersion field, encode the version
of a builtin using a mask that aligns better with version handling in
OpenCLOptions.h. In addition, this saves a field in the BuiltinTable.
This change allows a finer-grained control over the OpenCL versions in
which a builtin is available: instead of a range, we can now toggle
each version individually.
The fine-grained version control is not yet exposed on the TableGen
definitions side, as changes for OpenCL 3 feature optionality still
need to be defined and will affect how we want to expose these.
Differential Revision: https://reviews.llvm.org/D100492
This fixes a subtle issue where:
svprf(pg, ptr, SV_ALL /*is sv_pattern instead of sv_prfop*/)
would be quietly accepted. With this change, the function declaration
guards that the third parameter is a `enum sv_prfop`. Previously `svprf`
would map directly to `__builtin_sve_svprfb`, which accepts the enum
operand as a signed integer and only checks that the incoming range is
valid, meaning that SV_ALL would be discarded as being outside the valid
immediate range, but would have allowed SV_VL1 without issuing a warning
(C) or error (C++).
Reviewed By: c-rhodes
Differential Revision: https://reviews.llvm.org/D100297
The previous implementation was insufficient for checking statement
attribute mutual exclusion because attributed statements do not collect
their attributes one-at-a-time in the same way that declarations do. So
the design that was attempting to check for mutual exclusion as each
attribute was processed would not ever catch a mutual exclusion in a
statement. This was missed due to insufficient test coverage, which has
now been added for the [[likely]] and [[unlikely]] attributes.
The new approach is to check all of attributes that are to be applied
to the attributed statement in a group. This required generating
another DiagnoseMutualExclusions() function into AttrParsedAttrImpl.inc.
This patch changes the builtin prototype to use 'b' (boolean) instead
of the default integer element type. That fixes the dup/dupq intrinsics
when compiling with C++.
This patch also fixes one of the defines for __ARM_FEATURE_SVE2_BITPERM.
Reviewed By: kmclaughlin
Differential Revision: https://reviews.llvm.org/D100294
1. Redefine vpopc and vfirst IR intrinsic so it could adapt on
clang tablegen generator which always appends a type for vl
in IntrinsicType of clang codegen.
2. Remove `c` type transformer and add `u` and `l` for unsigned long
and long type.
Authored-by: Roger Ferrer Ibanez <rofirrim@gmail.com>
Co-Authored-by: Zakk Chen <zakk.chen@sifive.com>
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D100120
Just because an attribute is a statement attribute doesn't mean it's
not also a declaration attribute. In Clang, there are not currently any
DeclOrStmtAttr attributes that require mutual exclusion checking, but
downstream clients discovered this issue.
Currently, when one or more attributes are mutually exclusive, the
developer adding the attribute has to manually emit diagnostics. In
practice, this is highly error prone, especially for declaration
attributes, because such checking is not trivial. Redeclarations
require you to write a "merge" function to diagnose mutually exclusive
attributes and most attributes get this wrong.
This patch introduces a table-generated way to specify that a group of
two or more attributes are mutually exclusive:
def : MutualExclusions<[Attr1, Attr2, Attr3]>;
This works for both statement and declaration attributes (but not type
attributes) and the checking is done either from the common attribute
diagnostic checking code or from within mergeDeclAttribute() when
merging redeclarations.
RVV intrinsics has new overloading rule, please see
82aac7dad4
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
Support Complex type transformer to define more complexity legal type.
Overall our downstream implementation there are only four instructions need to
use complex type transformer, it's not a common case.
I still feel using a string for prototypes is simple and clear.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D98848
This requires changes to TableGen files and some C++ files due to
incompatible multiclass template arguments that slipped through
before the improved handling.
Clang currently automates a fair amount of diagnostic checking for
declaration attributes based on the declarations in Attr.td. It checks
for things like subject appertainment, number of arguments, language
options, etc. This patch uses the same machinery to perform diagnostic
checking on statement attributes.
Add new field PermuteOperands to mapping different operand order between
C/C++ API and clang builtin.
Reviewed By: craig.topper, rogfer01
Authored-by: Roger Ferrer Ibanez <rofirrim@gmail.com>
Co-Authored-by: Hsiangkai Wang <kai.wang@sifive.com>
Co-Authored-by: Zakk Chen <zakk.chen@sifive.com>
Differential Revision: https://reviews.llvm.org/D98388
In BuiltinsRISCV.def, other extension 's intrinsics need to be defined by using macro BUILTIN.
So, it shouldn't undefine macro BUILTIN in the end of declaration for V intrinsics.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D98682
This errors, but doesn't give source location. We'd need to pass
the Record through several layers to get to the location.
Reviewed By: jrtc27
Differential Revision: https://reviews.llvm.org/D98379
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 <rofirrim@gmail.com>
Co-Authored-by: Zakk Chen <zakk.chen@sifive.com>
Reviewed By: jrtc27, craig.topper, HsiangKai, Jim, Paul-C-Anagnostopoulos
Differential Revision: https://reviews.llvm.org/D95016
Allow users to use a non-system version of perl, python and awk, which is useful
in certain package managers.
Reviewed By: JDevlieghere, MaskRay
Differential Revision: https://reviews.llvm.org/D95119
This patch adds the following SHA3 Intrinsics:
vsha512hq_u64,
vsha512h2q_u64,
vsha512su0q_u64,
vsha512su1q_u64
veor3q_u8
veor3q_u16
veor3q_u32
veor3q_u64
veor3q_s8
veor3q_s16
veor3q_s32
veor3q_s64
vrax1q_u64
vxarq_u64
vbcaxq_u8
vbcaxq_u16
vbcaxq_u32
vbcaxq_u64
vbcaxq_s8
vbcaxq_s16
vbcaxq_s32
vbcaxq_s64
Note need to include +sha3 and +crypto when building from the front-end
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D96381
The inline keyword is not defined in the C89 standard, so source files
that include arm_sve.h will fail compilation if -std=c89 is specified.
For consistency with arm_neon.h, we should use __inline__ instead.
Reviewed By: paulwalker-arm
Differential Revision: https://reviews.llvm.org/D96852
Add enum and typedef argument support to `-fdeclare-opencl-builtins`,
which was the last major missing feature.
Adding the remaining missing builtins is left as future work.
Differential Revision: https://reviews.llvm.org/D96051
When newer build has duplicate issues the script tried to
remove it from the list more than once. The new approach
changes the way we filter out matching issues.
Differential Revision: https://reviews.llvm.org/D96611
Do not enforce that the expression to obtain the QualType for an
OpenCL type starts with an ASTContext. This adds the required
flexibility for handling the remaining missing argument types such as
enums.
Differential Revision: https://reviews.llvm.org/D96050
The implementation for (de)serialization of APValues can be shared
between Clang and Swift, so we prefer pushing the methods up
the inheritance hierarchy, instead of having the methods live in
ASTReader/ASTWriter. Fixes rdar://72592937.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D94196
This patch adds the LANE variants for VCMLA on AArch64 as defined in
"Arm Neon Intrinsics Reference for ACLE Q3 2020" [1]
This patch also updates `dup_typed` to accept constant type strings directly.
Based on a patch by Tim Northover.
[1] https://developer.arm.com/documentation/ihi0073/latest
Reviewed By: SjoerdMeijer
Differential Revision: https://reviews.llvm.org/D93014
This attribute permits a typedef to be associated with a class template
specialization as a preferred way of naming that class template
specialization. This permits us to specify that (for example) the
preferred way to express 'std::basic_string<char>' is as 'std::string'.
The attribute is applied to the various class templates in libc++ that have
corresponding well-known typedef names.
This is a re-commit. The previous commit was reverted because it exposed
a pre-existing bug that has since been fixed / worked around; see
PR48434.
Differential Revision: https://reviews.llvm.org/D91311
This change exposed a pre-existing issue with deserialization cycles
caused by a combination of attributes and template instantiations
violating the deserialization ordering restrictions; see PR48434 for
details.
A previous commit attempted to work around PR48434, but appears to have
only been a partial fix, and fixing this properly seems non-trivial.
Backing out for now to unblock things.
This reverts commit 98f76adf4e and
commit a64c26a47a.
This is really just a workaround for a more fundamental issue in the way
we deserialize attributes. See PR48434 for details.
Also fix tablegen code generator to produce more correct indentation to
resolve buildbot issues with -Werror=misleading-indentation firing
inside the generated code.
This attribute permits a typedef to be associated with a class template
specialization as a preferred way of naming that class template
specialization. This permits us to specify that (for example) the
preferred way to express 'std::basic_string<char>' is as 'std::string'.
The attribute is applied to the various class templates in libc++ that have
corresponding well-known typedef names.
Differential Revision: https://reviews.llvm.org/D91311
Adapt the declarations of `svpattern` and `svprfop` to the most recent
one defined in section "5. Enum declarations" of the SVE ACLE
specifications [1].
The signature of the intrinsics using these enums have been changed
accordingly.
A test has been added to make sure that `svpattern` and `svprfop` are
not typedefs.
[1] https://developer.arm.com/documentation/100987/latest, version
00bet6
Reviewed By: joechrisellis
Differential Revision: https://reviews.llvm.org/D91333
This was motivated by changes to llvm's `not --crash` disabling symbolization
but I ended up removing `not` from the script entirely because it
returns differently depending on whether clang "crashes" or exits for some
other reason. The script had to choose between calling `not` and `not --crash`
and sometimes it was wrong.
The script also now disables symbolization when we don't read the stack
trace because symbolizing is kind of slow.
Differential Revision: https://reviews.llvm.org/D91372
There are two factory functions used to create a semantic attribute,
Create() and CreateImplicit(). CreateImplicit() does not need to
specify the source range of the attribute since it's an implicitly-
generated attribute. The same logic does not apply to Create(), so
this removes the default argument from those declarations to avoid
accidentally creating a semantic attribute without source location
information.
Similar to the previous patch, this doesn't convert *all* the classes that
could be converted. It also doesn't enforce any new invariants etc.
It *does* include some data we don't use yet: specific token types that are
allowed and optional/required status of sequence items. (Similar to Dmitri's
prototype). I think these are easier to add as we go than later, and serve
a useful documentation purpose.
Differential Revision: https://reviews.llvm.org/D90659
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
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
In CUDA/HIP a function may become implicit host device function by
pragma or constexpr. A host device function is checked in both
host and device compilation. However it may be emitted only
on host or device side, therefore the diagnostics should be
deferred until it is known to be emitted.
Currently clang is only able to defer certain diagnostics. This causes
false alarms and limits the usefulness of host device functions.
This patch lets clang defer all overloading resolution diagnostics for host device functions.
An option -fgpu-defer-diag is added to control this behavior. By default
it is off.
It is NFC for other languages.
Differential Revision: https://reviews.llvm.org/D84364
Summary:
Whith the number of projects growing, it is important to be able to
filter them in a more convenient way than by names. It is especially
important for benchmarks, when it is not viable to analyze big
projects 20 or 50 times in a row.
Because of this reason, this commit adds a notion of sizes and a
filtering interface that puts a limit on a maximum size of the project
to analyze or benchmark.
Sizes assigned to the projects in this commit, do not directly
correspond to the number of lines or files in the project. The key
factor that is important for the developers of the analyzer is the
time it takes to analyze the project. And for this very reason,
"size" basically helps to cluster projects based on their analysis
time.
Differential Revision: https://reviews.llvm.org/D83942
ns_error_domain can be used by, e.g. NS_ERROR_ENUM, in order to
identify a global declaration representing the domain constant.
Introduces the attribute, Sema handling, diagnostics, and test case.
This is cherry-picked from a14779f504
and adapted to updated Clang APIs.
Reviewed By: gribozavr2, aaron.ballman
Differential Revision: https://reviews.llvm.org/D84005
WG14 N2481 was adopted with minor modifications at the latest WG14 meetings.
The only modification to the paper was to correct the date for the deprecated
attribute to be 201904L (the corrected date value will be present in WG14
N2553 when it gets published).
Before the patch `SATest compare`, produced quite obscure results
when something about the diagnostic have changed (i.e. its description
or the name of the corresponding checker) because it was simply two
lists of warnings, ADDED and REMOVED. It was up to the developer
to match those warnings, understand that they are essentially the
same, and figure out what caused the difference.
This patch introduces another category of results: MODIFIED.
It tries to match new warnings against the old ones and prints out
clues on what is different between two builds.
Differential Revision: https://reviews.llvm.org/D85311
Summary:
Not all projects in the project map file might have newer results
for updating, we should handle this situation gracefully.
Additionally, not every user of the test system would want storing
reference results in git. For this reason, git functionality is now
optional.
Differential Revision: https://reviews.llvm.org/D84303
ClangAttrEmitter.cpp generates ParsedAttr derived classes with virtual overrides in them (which end up in AttrParsedAttrImpl.inc); this patch ensures these generated functions are marked override, and not (redundantly) virtual.
I hesitate to say NFC since this does of course affect the behavior of the generator code, but the generated code behaves the same as it did before, so it's NFC in that sense.
Differential Revision: https://reviews.llvm.org/D83616
Summary:
This commit includes a couple of changes:
* Benchmark selected projects by analyzing them multiple times
* Compare two benchmarking results and visualizing them on one chart
* Organize project build logging, so we can use the same code
in benchmarks
Differential Revision: https://reviews.llvm.org/D83539
bfloat16 variants of svdup_lane were missing, and svcvtnt_bf16_x
was implemented incorrectly (it takes an operand for the inactive
lanes)
Reviewers: fpetrogalli, efriedma
Reviewed By: fpetrogalli
Tags: #clang
Differential Revision: https://reviews.llvm.org/D82908
The original patch was reverted in
ff5ccf258e
as it was missing the C tests that got accidentally missing.
This patch is a NFC of https://reviews.llvm.org/D82501, together with
the SVE ACLE tests for the C intrinsics of svreinterpret for brain
float types.
This reverts commit a15722c5ce.
The commmit has to be reverted because I accidentally submit
https://reviews.llvm.org/D82501 without the C tests that were added in
an early version of the patch.
Summary:
It generalizes the way the output looks across any -jN.
Additionally it solves the buffering problems.
Differential Revision: https://reviews.llvm.org/D81601
Summary:
Another possible difference between various users of the
testing system might be a change in dependencies installed on the
container. This commit tries to prevent any problem related to
different versions of the libraries/headers used and fixes them to
currently installed versions.
Differential Revision: https://reviews.llvm.org/D81600
Carlos Galvez