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
Summary:
Docker on its own has a pretty convenient way to run shell.
This method, however, requires target container to be currently running,
which is not a usual scenario for the test system. For this purpose,
it is better to have a simple way to run the container, shell it, and
clean up at the end of it all. New option `--shell` does exactly this.
Differential Revision: https://reviews.llvm.org/D81598
Summary:
If the user has only python2 installed and wants to use
the dockerized testing system, it is now totally OK.
Differential Revision: https://reviews.llvm.org/D81595
Summary:
Forward results of every command executed in docker. The actual commands
and their error codes are more informative than python stacktraces.
Differential Revision: https://reviews.llvm.org/D81593
Summary:
It provides a simpler interface for testing within docker.
This way the user is not required to no how to use `docker run` and
its options.
Differential Revision: https://reviews.llvm.org/D81572
Summary:
Static analysis is very sensitive to environment.
OS and libraries installed can affect the results. This fact makes
it extremely hard to have a regression testing system that will
produce stable results.
For this very reason, this commit introduces a new dockerized testing
environment, so that every analyzer developer can check their changes
against previous analysis results.
Differential Revision: https://reviews.llvm.org/D81571
Summary:
Whenever Neon is not supported, a generic message is printed:
error: "NEON support not enabled"
Followed by a series of other error messages that are not useful once
the first one is printed.
This patch gives a more precise message in the case where Neon is
unsupported because an invalid float ABI was specified: the soft float
ABI.
error: "NEON intrinsics not available with the soft-float ABI. Please
use -mfloat-abi=softfp or -mfloat-abi=hard"
This message is the same one that GCC gives, so it is also making their
diagnostics more compatible with each other.
Also, by rearranging preprocessor directives, these "unsupported" error
messages are now the only ones printed out, which is also GCC's
behaviour.
Differential Revision: https://reviews.llvm.org/D81847
This patch contains:
- Support in LLVM CodeGen for bfloat16 types for ld2/3/4 and st2/3/4.
- New bfloat16 ACLE builtins for svld(2|3|4)[_vnum] and svst(2|3|4)[_vnum]
Reviewers: stuij, efriedma, c-rhodes, fpetrogalli
Reviewed By: fpetrogalli
Tags: #clang, #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D82187
Summary:
svbfloat16_t should only be defined if the __ARM_FEATURE_SVE_BF16
feature macro is enabled, similar to the scalar bfloat16_t type. Also,
arm_bf16.h should be included in arm_sve.h when
__ARM_FEATURE_BF16_SCALAR_ARITHMETIC is defined.
Patch also contains a fix for ld1ro intrinsic which should be guarded on
__ARM_FEATURE_SVE_BF16 rather than __ARM_FEATURE_BF16_SCALAR_ARITHMETIC,
and a fix for bfmmla test which was missing
__ARM_FEATURE_BF16_SCALAR_ARITHMETIC and -target-feature +bf16 in the
RUN line.
Reviewed By: fpetrogalli
Differential Revision: https://reviews.llvm.org/D82178
Summary:
Handle `\l` separately because a string literal can be in code like "string\\literal" with the `\l` inside. Also on Windows macros __FILE__ produces specific delimiters `\` and a directory or file may starts with the letter `l`.
Fix:
Use regex for replacing all `\l` (like `,\l`, `}\l`, `[\l`) except `\\l`, because a literal as a rule contains multiple `\` before `\l`.
Differential Revision: https://reviews.llvm.org/D82092
Summary:
The new SVE builtin type __SVBFloat16_t` is used to represent scalable
vectors of bfloat elements.
Reviewers: sdesmalen, efriedma, stuij, ctetreau, shafik, rengolin
Subscribers: tschuett, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D81304
An AST serialization dump test is a test which compares the output of -ast-dump
on the source and of -ast-dump-all on a PCH generated from the source. Modulo
a few differences the outputs should match.
This patch to make-ast-dump-check.sh enables automatically generating
these tests.
Differential Revision: https://reviews.llvm.org/D81786
Reviewed By: aaron.ballman, lebedev.ri
Summary:
It makes it much harder to use from other modules when one of the
parameters is an argparse Namespace. This commit makes it easier
to use CmpRuns programmatically.
Differential Revision: https://reviews.llvm.org/D81566
Summary:
JSON format is a bit more verbose and easier to reason about
and extend. For this reason, before extending SATestBuild
functionality it is better to refactor the part of how we
configure the whole system.
Differential Revision: https://reviews.llvm.org/D81563
The AAPCS specifies that the tuple types such as `svint32x2_t`
should use their `arm_sve.h` names when mangled instead of their
builtin names.
This patch also renames the internal types for the tuples to
be prefixed with `__clang_`, so they are not misinterpreted as
specified internal types like the non-tuple types which *are* defined
in the AAPCS. Using a builtin type for the tuples is a purely
a choice of the Clang implementation.
Reviewers: rsandifo-arm, c-rhodes, efriedma, rengolin
Reviewed By: efriedma
Tags: #clang
Differential Revision: https://reviews.llvm.org/D81721
This patch adds new SVE types to Clang that describe tuples of SVE
vectors. For example `svint32x2_t` which maps to the twice-as-wide
vector `<vscale x 8 x i32>`. Similarly, `svint32x3_t` will map to
`<vscale x 12 x i32>`.
It also adds builtins to return an `undef` vector for a given
SVE type.
Reviewers: c-rhodes, david-arm, ctetreau, efriedma, rengolin
Reviewed By: c-rhodes
Tags: #clang
Differential Revision: https://reviews.llvm.org/D81459
Checker dependencies were added D54438 to solve a bug where the checker names
were incorrectly registered, for example, InnerPointerChecker would incorrectly
emit diagnostics under the name MallocChecker, or vice versa [1]. Since the
system over the course of about a year matured, our expectations of what a role
of a dependency and a dependent checker should be crystallized a bit more --
D77474 and its summary, as well as a variety of patches in the stack
demonstrates how we try to keep dependencies to play a purely modeling role. In
fact, D78126 outright forbids diagnostics under a dependency checkers name.
These dependencies ensured the registration order and enabling only when all
dependencies are satisfied. This was a very "strong" contract however, that
doesn't fit the dependency added in D79420. As its summary suggests, this
relation is directly in between diagnostics, not modeling -- we'd prefer a more
specific warning over a general one.
To support this, I added a new dependency kind, weak dependencies. These are not
as strict of a contract, they only express a preference in registration order.
If a weak dependency isn't satisfied, the checker may still be enabled, but if
it is, checker registration, and transitively, checker callback evaluation order
is ensured.
If you are not familiar with the TableGen changes, a rather short description
can be found in the summary of D75360. A lengthier one is in D58065.
[1] https://www.youtube.com/watch?v=eqKeqHRAhQM
Differential Revision: https://reviews.llvm.org/D80905
Summary:
The poly64 types are guarded with ifdefs for AArch64 only. This is wrong. This
was also incorrectly documented in the ACLE spec, but this has been rectified in
the latest release. See paragraph 13.1.2 "Vector data types":
https://developer.arm.com/docs/101028/latest
This patch was written by Alexandros Lamprineas.
Reviewers: ostannard, sdesmalen, fpetrogalli, labrinea, t.p.northover, LukeGeeson
Reviewed By: ostannard
Subscribers: pbarrio, LukeGeeson, kristof.beyls, danielkiss, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D79711
These cases all follow the same pattern:
struct A {
friend class X;
//...
class X {};
};
But 'friend class X;' injects 'X' into the surrounding namespace scope,
rather than introducing a class member. So the second 'class X {}' is a
completely different type, which changes the meaning of the earlier name
'X' from '::X' to 'A::X'.
Additionally, the friend declaration is pointless -- members of a class
don't need to be befriended to be able to access private members.
serge-sans-paille