This batch of intrinsics includes lots of things that move vector data
around or change its type without really affecting its value very
much. It includes the `vreinterpretq` family (cast one vector type to
another); `vuninitializedq` (create a vector of a given type with
don't-care contents); and `vcreateq` (make a 128-bit vector out of two
`uint64_t` halves).
These are all implemented using completely standard IR that's already
tested in existing LLVM unit tests, so I've just written a clang test
to check the IR is correct, and left it at that.
I've also added some richer infrastructure to the MveEmitter Tablegen
backend, to make it specify the exact integer type of integer
arguments passed to IR construction functions, and wrap those
arguments in a `static_cast` in the autogenerated C++. That was
necessary to prevent an overloading ambiguity when passing the integer
literal `0` to `IRBuilder::CreateInsertElement`, because otherwise, it
could mean either a null pointer `llvm::Value *` or a zero `uint64_t`.
Reviewers: ostannard, MarkMurrayARM, dmgreen
Subscribers: kristof.beyls, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D70133
This patch adds the ACLE intrinsics for all the MVE load and store
instructions not already handled by D69791. These ones don't need new
IR intrinsics, because they can be implemented in terms of standard
LLVM IR constructions.
Some of the load and store instructions access less than 128 bits of
memory, sign/zero extending each value to a wider vector lane on load
or truncating it on store. These are represented in IR by a load of a
shorter vector followed by a zext/sext, and conversely, a trunc
followed by a short store. Existing ISel patterns already recognize
those combinations and turn them into the right MVE instructions.
The predicated forms of all these instructions are represented in the
same way, except that the ordinary load/store operation is replaced
with the existing intrinsics @llvm.masked.{load,store}. These are
currently only code-generated as predicated MVE load/store
instructions if you give LLVM the `-enable-arm-maskedldst` option; so
I've done that in the LLVM codegen test. When we make that the
default, that option can be removed.
In the Tablegen backend, I've had to add a handful of extra support
features:
* We need to be able to make clang::Address objects out of a
pointer and an alignment (previously we only needed these when the
user passed us an existing one).
* We can now specify vector types that aren't 128 bits wide (for use
in those intermediate values in IR), the parametrized type system
can make one starting from two existing vector types (using the lane
count of one and the element type of the other).
* I've added support for code generation of pointer casts, and for
specifying LLVM types as operands to IRBuilder operations (for zext
and sext, though I think they'll come in useful again).
* Now not all IR construction operations need to be specified as
Builder.CreateFoo; some don't involve a Builder at all, and one
passes it as a parameter to a tiny static helper function in
CGBuiltin.cpp.
Reviewers: ostannard, MarkMurrayARM, dmgreen
Subscribers: kristof.beyls, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D70088
'a' used to implement a splat in C++ code in NeonEmitter.cpp, but this
can be done directly from .td expansions now (and most ops already did).
So removing it simplifies the overall code.
https://reviews.llvm.org/D69716
Previously we had a handful of bools (Signed, Floating, ...) that could
easily end up in an inconsistent state. This adds an enum Kind which
holds the mutually exclusive states a type might be in, retaining some
of the bools that modified an underlying type.
https://reviews.llvm.org/D69715
This patch adds two new families of intrinsics, both of which are
memory accesses taking a vector of locations to load from / store to.
The vldrq_gather_base / vstrq_scatter_base intrinsics take a vector of
base addresses, and an immediate offset to be added consistently to
each one. vldrq_gather_offset / vstrq_scatter_offset take a scalar
base address, and a vector of offsets to add to it. The
'shifted_offset' variants also multiply each offset by the element
size type, so that the vector is effectively of array indices.
At the IR level, these operations are represented by a single set of
four IR intrinsics: {gather,scatter} × {base,offset}. The other
details (signed/unsigned, shift, and memory element size as opposed to
vector element size) are all specified by IR intrinsic polymorphism
and immediate operands, because that made the selection job easier
than making a huge family of similarly named intrinsics.
I considered using the standard IR representations such as
llvm.masked.gather, but they're not a good fit. In order to use
llvm.masked.gather to represent a gather_offset load with element size
smaller than a pointer, you'd have to expand the <8 x i16> vector of
offsets into an <8 x i16*> vector of pointers, which would be split up
during legalization, so you'd spend most of your time undoing the mess
it had made. Also, ISel support for llvm.masked.gather would be easy
enough in a trivial way (you can expand it into a gather-base load
with a zero immediate offset), but instruction-selecting lots of
fiddly idioms back into all the _other_ MVE load instructions would be
much more work. So I think dedicated IR intrinsics are the more
sensible approach, at least for the moment.
On the clang tablegen side, I've added two new features to the
Tablegen source accepted by MveEmitter: a 'CopyKind' type node for
defining a type that varies with the parameter type (it lets you ask
for an unsigned integer type of the same width as the parameter), and
an 'unsignedflag' value node for passing an immediate IR operand which
is 0 for a signed integer type or 1 for an unsigned one. That lets me
write each kind of intrinsic just once and get all its subtypes and
immediate arguments generated automatically.
Also I've tweaked the handling of pointer-typed values in the code
generation part of MveEmitter: they're generated as Address rather
than Value (i.e. including an alignment) so that they can be given to
the ordinary IR load and store operations, but I'd omitted the code to
convert them back to Value when they're going to be used as an
argument to an IR intrinsic.
On the MC side, I've enhanced MVEVectorVTInfo so that it can tell you
not only the full assembly-language suffix for a given vector type
(like 's32' or 'u16') but also the numeric-only one used by store
instructions (just '32' or '16').
Reviewers: dmgreen
Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D69791
A few integer types in the ACLE definitions of MVE intrinsics are
given as 'int' or 'unsigned' instead of <stdint.h> fixed-size types
like uint32_t. Usually these are the ones where the size isn't that
important, such as immediate offsets in loads (which have a range
limited by the instruction encoding) or the carry flag in vadcq which
can only be 0 or 1 anyway.
With this change, <arm_mve.h> follows that exact type naming, so that
the function prototypes look identical to the ones in ACLE, instead of
replacing int and unsigned with int32_t and uint32_t.
Reviewers: dmgreen
Subscribers: kristof.beyls, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69790
In the code that generates Sema range checks on constant arguments, I
had a piece of code that checks the bounds specified in the Tablegen
intrinsic description against the range of the integer type being
tested. If the bounds are large enough to permit any value of the
integer type, you can omit the compile-time range check. (This case is
expected to come up in some of the bitwise operation intrinsics.)
But somehow I got my signed/unsigned check backwards (asking for the
signed min/max of an unsigned type and vice versa), and also made a
sign extension error in which a signed negative value gets
zero-extended. Now rewritten more sensibly, and it should get its
first sensible test from the next batch of intrinsics I'm planning to
add in D69791.
Reviewers: dmgreen
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69789
The TableGen-generated file containing the function definitions can be
reorganized to save some memory in the Clang binary. Functions having
the same prototype(s) will point to a shared list of prototype(s).
Patch by Pierre Gondois and Sven van Haastregt.
Differential Revision: https://reviews.llvm.org/D63557
Add handling for the "pure", "const" and "convergent" function
attributes for OpenCL builtin functions.
Patch by Pierre Gondois and Sven van Haastregt.
Differential Revision: https://reviews.llvm.org/D64319
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
ExplodedGraph nodes will now have a numeric identifier stored in them
which will keep track of the order in which the nodes were created
and it will be fully deterministic both accross runs and across machines.
This is extremely useful for debugging as it allows reliably setting
conditional breakpoints by node IDs.
llvm-svn: 375186
Because cast expressions have their own hierarchy, it's extremely useful
to have some information about what kind of casts are we dealing with.
llvm-svn: 375185
It's completely impossible to check that I've actually found all the
issues, due to the use of macros in arm_neon.h, but hopefully this time
it'll take more than a few hours for someone to find another issue.
I have no idea why, but apparently there's a rule that some, but not
all, builtins which should take an fp16 vector actually take an int8
vector as an argument. Fix this, and add test coverage.
Differential Revision: https://reviews.llvm.org/D68838
llvm-svn: 375179
Just running -fsyntax-only over arm_neon.h doesn't cover some intrinsics
which are defined using macros. Add more test coverage for that.
arm-neon-header.c wasn't checking the full set of available NEON target
features; change the target architecture of the test to account for
that.
Fix the generator for arm_neon.h to generate casts in more cases where
they are necessary.
Fix VFMLAL_LOW etc. to express their signatures differently, so the
builtins have the expected type. Maybe the TableGen backend should
detect intrinsics that are defined the wrong way, and produce an error.
The rules here are sort of strange.
Differential Revision: https://reviews.llvm.org/D68743
llvm-svn: 374419
Really, we were already 99% of the way there; just needed a couple minor
fixes that affected 64-bit-only builtins. Based on D61717.
Note that the change to builtin_str changes the type of a few
__builtin_neon_* intrinsics that had the "wrong" type.
Fixes https://bugs.llvm.org/show_bug.cgi?id=43341
Differential Revision: https://reviews.llvm.org/D68683
llvm-svn: 374191
Add install targets as necessary to install bash-autocomplete,
scan-build and scan-view via LLVM_DISTRIBUTION_TARGETS.
Differential Revision: https://reviews.llvm.org/D68413
llvm-svn: 373695
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
Allow setting a MinVersion, stating from which OpenCL version a
builtin function is available, and a MaxVersion, stating from which
OpenCL version a builtin function should not be available anymore.
Guard some definitions of the "work-item" builtin functions according
to the OpenCL versions from which they are available.
Add the "vector data load and store" builtin functions (e.g.
vload/vstore), whose signatures differ before and after OpenCL 2.0 in
the pointer argument address spaces.
Patch by Pierre Gondois and Sven van Haastregt.
Differential Revision: https://reviews.llvm.org/D63504
llvm-svn: 372321
r371875 moved some functionality around to a Basic header file, but
didn't move its definitions as well. This patch moves some things
around so that shared library building can work.
llvm-svn: 371985
Apparently Clang complains about the name hiding here in a way that my
GCC build does not, so a shocking number of buildbots decided to tell me
about it. Change the name of the variable to prevent the name hiding
and hope we don't have to fix this again.
llvm-svn: 371876
In order to enable future improvements to our attribute diagnostics,
this moves info from ParsedAttr into CommonAttributeInfo, then makes
this type the base of the *Attr and ParsedAttr types. Quite a bit of
refactoring took place, including removing a bunch of redundant Spelling
Index propogation.
Differential Revision: https://reviews.llvm.org/D67368
llvm-svn: 371875
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
Image types were previously available, but not working. This patch
adds image type handling.
Rename the image type definitions in the .td file to make them
consistent with other type names. Use abstract types to represent the
unqualified types. Instantiate access-qualified image types at the
point of use using, e.g. `ImageType<Image2d, "RO">`.
Add/update TableGen definitions for the read_image/write_image
builtin functions.
Patch by Pierre Gondois and Sven van Haastregt.
Differential Revision: https://reviews.llvm.org/D63480
llvm-svn: 371046
Breaks BUILD_SHARED_LIBS build, introduces cycles in library dependency
graphs. (clangInterp depends on clangAST which depends on clangInterp)
This reverts r370839, which is an yet another recommit of D64146.
llvm-svn: 370874
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: 370839
Summary:
The declaration of arm neon intrinsics that are
"big endian safe" print the same code for big
and small endian targets.
This patch avoids duplicates by checking if an
intrinsic is safe to have a single definition.
(decreases header 11k lines out of 73k).
Reviewers: t.p.northover, ostannard, labrinea
Reviewed By: ostannard
Subscribers: kristof.beyls, cfe-commits, olista01
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66588
llvm-svn: 370716
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: 370636
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: 370584
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: 370531
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: 370476
Const, volatile, and pointer types were previously available, but not
working. This patch adds handling for OpenCL builtin functions.
Add TableGen definitions for some atomic and asynchronous builtins to
make use of the new functionality.
Patch by Pierre Gondois and Sven van Haastregt.
Differential Revision: https://reviews.llvm.org/D63442
llvm-svn: 369373
Generic types are an abstraction of type sets. It mimics the way
functions are defined in the OpenCL specification. For example,
floatN can abstract all the vector sizes of the float type.
This allows to
* stick more closely to the specification, which uses generic types;
* factorize definitions of functions with numerous prototypes in the
tablegen file; and
* reduce the memory impact of functions with many overloads.
Patch by Pierre Gondois and Sven van Haastregt.
Differential Revision: https://reviews.llvm.org/D65456
llvm-svn: 369253
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.
Differential revision: https://reviews.llvm.org/D66259
llvm-svn: 368942
They're useful when trying to understand what's going on
inside your LazyCompoundValues.
Differential Revision: https://reviews.llvm.org/D65427
llvm-svn: 368769
When -trim-egraph is unavailable (say, when you're debugging a crash on
a real-world code that takes too long to reduce), it makes sense to view
the untrimmed graph up to the crashing node's predecessor, then dump the ID
(or a pointer) of the node in the attached debugger, and then trim
the dumped graph in order to keep only paths from the root to the node.
The newly added --to flag does exactly that:
$ exploded-graph-rewriter.py ExprEngine.dot --to 0x12229acd0
Multiple nodes can be specified. Stable IDs of nodes can be used
instead of pointers.
Differential Revision: https://reviews.llvm.org/D65345
llvm-svn: 368768
Explorers aren't the right abstraction. For the purposes of displaying svg files
we don't care in which order do we explore the nodes. We may care about this for
other analyses, but we're not there yet.
The function of cutting out chunks of the graph is performed poorly by
the explorers, because querying predecessors/successors on the explored nodes
yields original successors/predecessors even if they aren't being explored.
Introduce a new entity, "trimmers", that do one thing but to it right: cut out
chunks of the graph. Trimmers mutate the graph, so stale edges aren't even
visible to their consumers in the pipeline. Additionally, trimmers are
intrinsically composable: multiple trimmers can be applied to the graph
sequentially.
Refactor the single-path explorer into the single-path trimmer.
Rename the test file for consistency.
Differential Revision: https://reviews.llvm.org/D65344
llvm-svn: 368767
Change the default behavior: the tool no longer dumps the rewritten .dot file
to stdout, but instead it automatically converts it into an .html file
(which essentially wraps an .svg file) and immediately opens it with
the default web browser.
This means that the tool should now be fairly easy to use:
$ exploded-graph-rewriter.py /tmp/ExprEngine.dot
The benefits of wrapping the .svg file into an .html file are:
- It'll open in a web browser, which is the intended behavior.
An .svg file would be open with an image viewer/editor instead.
- It avoids the white background around the otherwise dark svg area
in dark mode.
The feature can be turned off by passing a flag '--rewrite-only'.
The LIT substitution is updated to enforce the old mode because
we don't want web browsers opening on our buildbots.
Differential Revision: https://reviews.llvm.org/D65250
llvm-svn: 368766
DeclSpec now shows the TypeRep, ExprRep, or DeclRep as appropriate
TemplateName decodes and displays the StorageType
A few minor refinements to other types
llvm-svn: 367199
Summary:
This is the first part of work announced in
"[RFC] Adding lifetime analysis to clang" [0],
i.e. the addition of the [[gsl::Owner(T)]] and
[[gsl::Pointer(T)]] attributes, which
will enable user-defined types to participate in
the lifetime analysis (which will be part of the
next PR).
The type `T` here is called "DerefType" in the paper,
and denotes the type that an Owner owns and a Pointer
points to. E.g. `std::vector<int>` should be annotated
with `[[gsl::Owner(int)]]` and
a `std::vector<int>::iterator` with `[[gsl::Pointer(int)]]`.
[0] http://lists.llvm.org/pipermail/cfe-dev/2018-November/060355.html
Reviewers: gribozavr
Subscribers: xazax.hun, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D63954
llvm-svn: 367040
This reverts commit 9178b10163 (r365969).
We are back to using Python2 and this is failing. This should instead be made
to be compatible with both Python 2 and 3.
llvm-svn: 366953
Some targets such as Python 2.7.16 still use VERSION in
their builds. Without VERSION defined, the source code
has syntax errors.
Reverting as it will probably break many other things.
Noticed by Sterling Augustine
llvm-svn: 365992
Summary:
It has been introduced in 2011 for gcc compat:
ad1a4c6e89
it is probably time to remove it
Reviewers: rnk, dexonsmith
Reviewed By: rnk
Subscribers: dschuff, aheejin, fedor.sergeev, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64062
llvm-svn: 365962
- Correctly display macro expansion and spelling locations.
- Use the same procedure to display location context call site locations.
- Display statement IDs for program points.
llvm-svn: 365861
In this mode the rewriter will only rewrite program points
and omit program states. Useful for understanding
the rough topology of the graph.
Differential Revision: https://reviews.llvm.org/D64264
llvm-svn: 365410
Instead of rewriting the whole graph, rewrite the leftmost path in the
graph. Useful for trimmed graphs that are still too large to display due
to multiple equivalent reports mixed into them.
Differential Revision: https://reviews.llvm.org/D64263
llvm-svn: 365409
Now shows the actual annotated template. E.g.,
{annot_template_id (A<int, double>)}
Also a few miscellaneous fixes to visualizers of other types
llvm-svn: 365248
Add a label to nodes that have a bug report attached or on which
the analysis was generally interrupted.
Fix printing has_report and implement printing is_sink in the graph dumper.
Differential Revision: https://reviews.llvm.org/D64110
llvm-svn: 364992
When printing various statements that include braces (compound
statements, lambda expressions, statement-expressions, etc.),
replace the code between braces with '...'.
Differential Revision: https://reviews.llvm.org/D64104
llvm-svn: 364990
Slightly cleanup emission of horizontal lines and unhardcode the title
for generic maps.
Differential Revision: https://reviews.llvm.org/D64041
llvm-svn: 364865
Make more consistent use of na format.
Improve visualization of deduction guides.
Add visualizer for explicit specifier (including conditionally explicit)
Fix some typos
llvm-svn: 364724
Diff support included.
A cheap solution is implemented that treats range constraints as
"some sort of key-value map", so it's going to be trivial
to add support for other such maps later, such as dynamic type info.
Differential Revision: https://reviews.llvm.org/D63685
llvm-svn: 364268
For example, the following TypeAliasTemplateDecl now displays in the autos window as
template<class T> using type_identity_t = type_identity<T>::type;
llvm-svn: 364145
Summary:
Add support for the C++2a [[no_unique_address]] attribute for targets using the Itanium C++ ABI.
This depends on D63371.
Reviewers: rjmccall, aaron.ballman
Subscribers: dschuff, aheejin, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D63451
llvm-svn: 363976
In this mode the tool would avoid duplicating the contents of the
program state on every node, replacing them with a diff-like dump
of changes that happened on that node.
This is useful because most of the time we only interested in whether
the effect of the statement was modeled correctly. A diffed graph would
also be much faster to load and navigate, being much smaller than
the original graph.
The diffs are computed "semantically" as opposed to plain text diffs.
I.e., the diff algorithm is hand-crafted separately for every state trait,
taking the underlying data structures into account. This is especially nice
for Environment because textual diffs would have been terrible.
On the other hand, it requires some boilerplate to implement.
Differential Revision: https://reviews.llvm.org/D62761
llvm-svn: 363898
Quotes around StringRegions are now escaped and unescaped correctly,
producing valid JSON.
Additionally, add a forgotten escape for Store values.
Differential Revision: https://reviews.llvm.org/D63519
llvm-svn: 363897
This change adds/improves MSVC visualizers for many Clang types, including array types, trailing return types in function, deduction guides, a fix for OpaquePtr, etc. It also replaces all of the view(deref) with the "na" formatter, which is a better built-in natvis technique for doing the same thing.
Differential Revision: https://reviews.llvm.org/D63039
llvm-svn: 363574
This patch adds a `-fdeclare-opencl-builtins` command line option to
the clang frontend. This enables clang to verify OpenCL C builtin
function declarations using a fast StringMatcher lookup, instead of
including the opencl-c.h file with the `-finclude-default-header`
option. This avoids the large parse time penalty of the header file.
This commit only adds the basic infrastructure and some of the OpenCL
builtins. It does not cover all builtins defined by the various OpenCL
specifications. As such, it is not a replacement for
`-finclude-default-header` yet.
RFC: http://lists.llvm.org/pipermail/cfe-dev/2018-November/060041.html
Co-authored-by: Pierre Gondois
Co-authored-by: Joey Gouly
Co-authored-by: Sven van Haastregt
Differential Revision: https://reviews.llvm.org/D60763
llvm-svn: 362371
This is a utility to improve readability and generally manipulate
GraphViz dumps of the analysis graph. Such dumps are often huge and
not only hard to read, but also often hang the viewer apps with their
mere size. Such script should significantly improve debugging experience.
Differential Revision: https://reviews.llvm.org/D62638
llvm-svn: 362340
regenerate the test expectations.
(Only two tests change, as a result of no longer matching the 0x in a
pointer; the other tests were already excluding that.)
llvm-svn: 362316
Swift requires certain classes to be not just initialized lazily on first
use, but actually allocated lazily using information that is only available
at runtime. This is incompatible with ObjC class initialization, or at least
not efficiently compatible, because there is no meaningful class symbol
that can be put in a class-ref variable at load time. This leaves ObjC
code unable to access such classes, which is undesirable.
objc_class_stub says that class references should be resolved by calling
a new ObjC runtime function with a pointer to a new "class stub" structure.
Non-ObjC compilers (like Swift) can simply emit this structure when ObjC
interop is required for a class that cannot be statically allocated,
then apply this attribute to the `@interface` in the generated ObjC header
for the class.
This attribute can be thought of as a generalization of the existing
`objc_runtime_visible` attribute which permits more efficient class
resolution as well as supporting the additon of categories to the class.
Subclassing these classes from ObjC is currently not allowed.
Patch by Slava Pestov!
llvm-svn: 362054
Same patch as D62093, but for checker/plugin options, the only
difference being that options for alpha checkers are implicitly marked
as alpha.
Differential Revision: https://reviews.llvm.org/D62093
llvm-svn: 361566
These options are now only visible under
-analyzer-checker-option-help-developer.
Differential Revision: https://reviews.llvm.org/D61839
llvm-svn: 361561
During my work on analyzer dependencies, I created a great amount of new
checkers that emitted no diagnostics at all, and were purely modeling some
function or another.
However, the user shouldn't really disable/enable these by hand, hence this
patch, which hides these by default. I intentionally chose not to hide alpha
checkers, because they have a scary enough name, in my opinion, to cause no
surprise when they emit false positives or cause crashes.
The patch introduces the Hidden bit into the TableGen files (you may remember
it before I removed it in D53995), and checkers that are either marked as
hidden, or are in a package that is marked hidden won't be displayed under
-analyzer-checker-help. -analyzer-checker-help-hidden, a new flag meant for
developers only, displays the full list.
Differential Revision: https://reviews.llvm.org/D60925
llvm-svn: 359720
TL;DR:
* Add checker and package options to the TableGen files
* Added a new class called CmdLineOption, and both Package and Checker recieved
a list<CmdLineOption> field.
* Added every existing checker and package option to Checkers.td.
* The CheckerRegistry class
* Received some comments to most of it's inline classes
* Received the CmdLineOption and PackageInfo inline classes, a list of
CmdLineOption was added to CheckerInfo and PackageInfo
* Added addCheckerOption and addPackageOption
* Added a new field called Packages, used in addPackageOptions, filled up in
addPackage
Detailed description:
In the last couple months, a lot of effort was put into tightening the
analyzer's command line interface. The main issue is that it's spectacularly
easy to mess up a lenghty enough invocation of the analyzer, and the user was
given no warnings or errors at all in that case.
We can divide the effort of resolving this into several chapters:
* Non-checker analyzer configurations:
Gather every analyzer configuration into a dedicated file. Emit errors for
non-existent configurations or incorrect values. Be able to list these
configurations. Tighten AnalyzerOptions interface to disallow making such
a mistake in the future.
* Fix the "Checker Naming Bug" by reimplementing checker dependencies:
When cplusplus.InnerPointer was enabled, it implicitly registered
unix.Malloc, which implicitly registered some sort of a modeling checker
from the CStringChecker family. This resulted in all of these checker
objects recieving the name "cplusplus.InnerPointer", making AnalyzerOptions
asking for the wrong checker options from the command line:
cplusplus.InnerPointer:Optimisic
istead of
unix.Malloc:Optimistic.
This was resolved by making CheckerRegistry responsible for checker
dependency handling, instead of checkers themselves.
* Checker options: (this patch included!)
Same as the first item, but for checkers.
(+ minor fixes here and there, and everything else that is yet to come)
There were several issues regarding checker options, that non-checker
configurations didn't suffer from: checker plugins are loaded runtime, and they
could add new checkers and new options, meaning that unlike for non-checker
configurations, we can't collect every checker option purely by generating code.
Also, as seen from the "Checker Naming Bug" issue raised above, they are very
rarely used in practice, and all sorts of skeletons fell out of the closet while
working on this project.
They were extremely problematic for users as well, purely because of how long
they were. Consider the following monster of a checker option:
alpha.cplusplus.UninitializedObject:CheckPointeeInitialization=false
While we were able to verify whether the checker itself (the part before the
colon) existed, any errors past that point were unreported, easily resulting
in 7+ hours of analyses going to waste.
This patch, similarly to how dependencies were reimplemented, uses TableGen to
register checker options into Checkers.td, so that Checkers.inc now contains
entries for both checker and package options. Using the preprocessor,
Checkers.inc is converted into code in CheckerRegistry, adding every builtin
(checkers and packages that have an entry in the Checkers.td file) checker and
package option to the registry. The new addPackageOption and addCheckerOption
functions expose the same functionality to statically-linked non-builtin and
plugin checkers and packages as well.
Emitting errors for incorrect user input, being able to list these options, and
some other functionalies will land in later patches.
Differential Revision: https://reviews.llvm.org/D57855
llvm-svn: 358752
Some more additions to the script - mainly reducing the clang args after
the creduce run by removing them one by one and seeing if the crash
reproduces. Other things:
- remove the --crash flag when "fatal error" occurs
- fixed to read stack trace functions from the top
- run creduce on a copy of the original file
Patch by Amy Huang!
Differential Revision: https://reviews.llvm.org/D59725
llvm-svn: 357290
This CL causes our creduce-clang-crash.py util to:
- try to preprocess the file before reducing
- try to remove some command line arguments
- now require a llvm bin directory, since the generated crash script
doesn't have an absolute path for clang
It also marks it as executable, since I forgot to do that in the last
commit. :)
Patch by Amy Huang!
Differential Revision: https://reviews.llvm.org/D59440
llvm-svn: 356636
This CL adds a script that calls C-Reduce on an input file and given the
clang crash script, which is used to generate an interestingness test
for C-Reduce.
Patch by Amy Huang!
Differential Revision: https://reviews.llvm.org/D59118
llvm-svn: 355944
Unfortunately, up until now, the fact that certain checkers depended on one
another was known, but how these actually unfolded was hidden deep within the
implementation. For example, many checkers (like RetainCount, Malloc or CString)
modelled a certain functionality, and exposed certain reportable bug types to
the user. For example, while MallocChecker models many many different types of
memory handling, the actual "unix.MallocChecker" checker the user was exposed to
was merely and option to this modeling part.
Other than this being an ugly mess, this issue made resolving the checker naming
issue almost impossible. (The checker naming issue being that if a checker
registered more than one checker within its registry function, both checker
object recieved the same name) Also, if the user explicitly disabled a checker
that was a dependency of another that _was_ explicitly enabled, it implicitly,
without "telling" the user, reenabled it.
Clearly, changing this to a well structured, declarative form, where the
handling of dependencies are done on a higher level is very much preferred.
This patch, among the detailed things later, makes checkers declare their
dependencies within the TableGen file Checkers.td, and exposes the same
functionality to plugins and statically linked non-generated checkers through
CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies,
makes sure that checkers are added to CheckerManager in the correct order,
and makes sure that if a dependency is disabled, so will be every checker that
depends on it.
In detail:
* Add a new field to the Checker class in CheckerBase.td called Dependencies,
which is a list of Checkers.
* Move unix checkers before cplusplus, as there is no forward declaration in
tblgen :/
* Add the following new checkers:
- StackAddrEscapeBase
- StackAddrEscapeBase
- CStringModeling
- DynamicMemoryModeling (base of the MallocChecker family)
- IteratorModeling (base of the IteratorChecker family)
- ValistBase
- SecuritySyntaxChecker (base of bcmp, bcopy, etc...)
- NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker)
- IvarInvalidationModeling (base of IvarInvalidation checker family)
- RetainCountBase (base of RetainCount and OSObjectRetainCount)
* Clear up and registry functions in MallocChecker, happily remove old FIXMEs.
* Add a new addDependency function to CheckerRegistry.
* Neatly format RUN lines in files I looked at while debugging.
Big thanks to Artem Degrachev for all the guidance through this project!
Differential Revision: https://reviews.llvm.org/D54438
llvm-svn: 352287
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
With commit r351627, LLVM gained the ability to apply (existing) IPO
optimizations on indirections through callbacks, or transitive calls.
The general idea is that we use an abstraction to hide the middle man
and represent the callback call in the context of the initial caller.
It is described in more detail in the commit message of the LLVM patch
r351627, the llvm::AbstractCallSite class description, and the
language reference section on callback-metadata.
This commit enables clang to emit !callback metadata that is
understood by LLVM. It does so in three different cases:
1) For known broker functions declarations that are directly
generated, e.g., __kmpc_fork_call for the OpenMP pragma parallel.
2) For known broker functions that are identified by their name and
source location through the builtin detection, e.g.,
pthread_create from the POSIX thread API.
3) For user annotated functions that carry the "callback(callee, ...)"
attribute. The attribute has to include the name, or index, of
the callback callee and how the passed arguments can be
identified (as many as the callback callee has). See the callback
attribute documentation for detailed information.
Differential Revision: https://reviews.llvm.org/D55483
llvm-svn: 351629
Remove now-vestigial dumpType and dumpBareDeclRef methods. The old
tablegen generated code used to expect them to be present, but the new
generated code has no such requirement.
Reviewers: aaron.ballman
Subscribers: mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D55492
llvm-svn: 350958
Current clang fail to bootstrap in PGO mode when only python3 is available,
because perf-helper.py is not compatible with python3.
Commited on behalf of Romain Geissler.
Differential Revision: https://reviews.llvm.org/D54071
llvm-svn: 350955
This adds anchors to all of the documented checks so that you can directly link to a check by a stable name. This is useful because the SARIF file format has a field for specifying a URI to documentation for a rule and some viewers, like CodeSonar, make use of this information. These links are then exposed through the SARIF exporter.
llvm-svn: 349812
This updates the FunctionProtoType visualizer to use the proper bits for determining parameter information and the DeclarationName visualizer to use the detail namespace. It also adds support for viewing newer special declaration names (like deduction guides).
Patch with help of Bruno Ricci.
llvm-svn: 349547
In Python3, dict.items, dict.keys, dict.values, zip, map and filter no longer return lists, they create generator instead.
The portability patch consists in forcing an extra `list` call if the result is actually used as a list.
`map` are replaced by list comprehension and `filter` by filtered list comprehension.
Differential Revision: https://reviews.llvm.org/D55197
llvm-svn: 349501
In Python2, division between integer yields an integer, while it yields a float in Python3.
Use a combination of from __future__ import division and // operator to get a portable behavior.
Differential Revision: https://reviews.llvm.org/D55204
llvm-svn: 349455
Using from __future__ import print_function it is possible to have a compatible behavior of `print(...)` across Python version.
Differential Revision: https://reviews.llvm.org/D55213
llvm-svn: 349454
Replace `xrange(...)` by either `range(...)` or `list(range(...))` depending on the context.
Differential Revision: https://reviews.llvm.org/D55193
llvm-svn: 349448
Downstream forks that have their own attributes often run into this
test failing when a new attribute is added to clang because the
number of supported attributes no longer match. This is redundant
information for this test, so we can get by without it.
rdar://46288577
llvm-svn: 348218
Have all classes derive from object: that's implicitly the default in Python3,
it needs to be done explicilty in Python2.
Differential Revision: https://reviews.llvm.org/D55121
llvm-svn: 348127
Python2 supports the two following equivalent construct
raise ExceptionType, exception_value
and
raise ExceptionType(exception_value)
Only the later is supported by Python3.
Differential Revision: https://reviews.llvm.org/D55195
llvm-svn: 348126
Generate the FP16FML intrinsics into arm_neon.h (AArch64 only for now).
Add two new type modifiers to NeonEmitter to handle the new prototypes.
Define __ARM_FEATURE_FP16FML when +fp16fml is enabled and guard the
intrinsics with the macro in arm_neon.h.
Based on a patch by Gao Yiling.
Differential Revision: https://reviews.llvm.org/D53633
llvm-svn: 345344
There are a few leftovers of rC343147 that are not (\w+)\.begin but in
the form of ([-[:alnum:]>.]+)\.begin or spanning two lines. Change them
to use the container form in this commit. The 12 occurrences have been
inspected manually for safety.
llvm-svn: 343425
Simon Tatham