Summary:
This change adds a `ni` specifier in the `datalayout` string to denote
pointers in some given address spaces as "non-integral", and adds some
typing rules around these special pointers.
Reviewers: majnemer, chandlerc, atrick, dberlin, eli.friedman, tstellarAMD, arsenm
Subscribers: arsenm, mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D22488
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277085 91177308-0d34-0410-b5e6-96231b3b80d8
This adds boilerplate code for all coroutine passes,
the passes are no-ops for now.
Also, a small test has been added to verify that passes execute in
the expected order or not at all if coroutine support is disabled.
Patch by Gor Nishanov!
Differential Revision: https://reviews.llvm.org/D22847
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277033 91177308-0d34-0410-b5e6-96231b3b80d8
This enables users to export coverage information as portable JSON for use by
analysis tools and storage in document based databases.
The export sub-command is invoked just like the others:
llvm-cov export -instr-profile path/to/foo.profdata path/to/foo.binary
The resulting JSON contains a list of files and functions. Every file object
contains a list of segments, expansions, and a summary of the file's region,
function, and line coverage. Every function object contains the function's name
and regions. There is also a total summary for the entire object file.
Changes since the initial commit (r276813):
- Fixed the regexes in the tests to handle Windows filepaths.
Patch by Eddie Hurtig!
Differential Revision: https://reviews.llvm.org/D22651
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276818 91177308-0d34-0410-b5e6-96231b3b80d8
This enables users to export coverage information as portable JSON for use by
analysis tools and storage in document based databases.
The export sub-command is invoked just like the others:
llvm-cov export -instr-profile path/to/foo.profdata path/to/foo.binary
The resulting JSON contains a list of files and functions. Every file object
contains a list of segments, expansions, and a summary of the file's region,
function, and line coverage. Every function object contains the function's name
and regions. There is also a total summary for the entire object file.
Patch by Eddie Hurtig!
Differential Revision: https://reviews.llvm.org/D22651
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276813 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The llvm.invariant.start and llvm.invariant.end intrinsics currently
support specifying invariant memory objects only in the default address
space.
With this change, these intrinsics are overloaded for any adddress space
for memory objects
and we can use these llvm invariant intrinsics in non-default address
spaces.
Example: llvm.invariant.start.p1i8(i64 4, i8 addrspace(1)* %ptr)
This overloaded intrinsic is needed for representing final or invariant
memory in managed languages.
Reviewers: apilipenko, reames
Subscribers: llvm-commits
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276447 91177308-0d34-0410-b5e6-96231b3b80d8
Given that other proposals are making their way through, it's better if we
specify what GitHub proposal this is, in case there are others that also
involve GitHub, but not sub-modules.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276325 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The llvm.invariant.start and llvm.invariant.end intrinsics currently
support specifying invariant memory objects only in the default address space.
With this change, these intrinsics are overloaded for any adddress space for memory objects
and we can use these llvm invariant intrinsics in non-default address spaces.
Example: llvm.invariant.start.p1i8(i64 4, i8 addrspace(1)* %ptr)
This overloaded intrinsic is needed for representing final or invariant memory in managed languages.
Reviewers: tstellarAMD, reames, apilipenko
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D22519
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276316 91177308-0d34-0410-b5e6-96231b3b80d8
Lots of blocks had "llvm" or "nasm" syntax types but either weren't following
the syntax, or the syntax has changed (and sphinx hasn't keep up) or the type
doesn't even exist (nasm?).
Other documents had :options: what were invalid. I only removed those that had
warnings, and left the ones that didn't, in order to follow the principle of
least surprise.
This is like this for ages, but the buildbot is now failing on errors. It may
take a while to upgrade the buildbot's sphinx, if that's even possible, but
that shouldn't stop us from getting docs updates (which seem down for quite
a while).
Also, we're not losing any syntax highlight, since when it doesn't parse, it
doesn't colour. Ie. those blocks are not being highlighted anyway.
I'm trying to get all docs in one go, so that it's easy to revert later if we
do fix, or at least easy to know what's to fix.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276109 91177308-0d34-0410-b5e6-96231b3b80d8
This will unblock the llvm-sphinx-buildbot, which is currently failing due
to a warning being treated as error.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276100 91177308-0d34-0410-b5e6-96231b3b80d8
This document was crafted from the various (320+) emails between 2nd June and
20th July regarding the move to GitHub. It tried to consolidate every issue that
was raised and every solution that was presented to have a GitHub repository
with sub-modules.
It *does not* try to argue whether sub-modules are better or worse than any other
Git solution, nor if Git is better than any other VCS, nor if GitHub is better
than any other free code hosting service. This is just the final conclusions of
48 days and 320 emails (plus a lot of IRC discussions) on the LLVM community.
This document will be presented at the survey that the foundation will setup for
us to decide if we move to this solution or not. It reflects what was discussed
on the lists, but it's not authoritative. If something is not clear enough,
please refer to the mailing list discussions (hint: search for "GitHub").
Review: https://reviews.llvm.org/D22463
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276097 91177308-0d34-0410-b5e6-96231b3b80d8
Add a "-j" option to llvm-profdata to control the number of threads used.
Auto-detect NumThreads when it isn't specified, and avoid spawning threads when
they wouldn't be beneficial.
I tested this patch using a raw profile produced by clang (147MB). Here is the
time taken to merge 4 copies together on my laptop:
No thread pool: 112.87s user 5.92s system 97% cpu 2:01.08 total
With 2 threads: 134.99s user 26.54s system 164% cpu 1:33.31 total
Changes since the initial commit:
- When handling odd-length inputs, call ThreadPool::wait() before merging the
last profile. Should fix a race/off-by-one (see r275937).
Differential Revision: https://reviews.llvm.org/D22438
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275938 91177308-0d34-0410-b5e6-96231b3b80d8
Add an overview of stubs and compile callbacks before the discussion of the
source changes.
-- This line, and those below, will be ignored--
M docs/tutorial/BuildingAJIT3.rst
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275933 91177308-0d34-0410-b5e6-96231b3b80d8
Add a "-j" option to llvm-profdata to control the number of threads
used. Auto-detect NumThreads when it isn't specified, and avoid spawning
threads when they wouldn't be beneficial.
I tested this patch using a raw profile produced by clang (147MB). Here is the
time taken to merge 4 copies together on my laptop:
No thread pool: 112.87s user 5.92s system 97% cpu 2:01.08 total
With 2 threads: 134.99s user 26.54s system 164% cpu 1:33.31 total
Differential Revision: https://reviews.llvm.org/D22438
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275921 91177308-0d34-0410-b5e6-96231b3b80d8
The default behavior of bugpoint is to print "<crash>" when it finds a reduced
test that crashes compilation. With this flag we now can see the output of the
crashing program. This is useful to make sure it is the same error being
tracked down and not a different error that happens to crash the compiler as
well.
Differential Revision: https://reviews.llvm.org/D22411
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275646 91177308-0d34-0410-b5e6-96231b3b80d8
Add an option to specify a symbol demangler (as well as options to the
demangler). This can be used to make reports more human-readable.
This option is especially useful in -output-dir mode, since it isn't as
easy to manually pipe reports into a demangler in this mode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275640 91177308-0d34-0410-b5e6-96231b3b80d8
This adds Clang-specific DWARF constants for nullability and ObjC
class properties that are already generated by clang. This patch adds
dwarfdump support and a more comprehensive testcase.
<rdar://problem/27335745>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275354 91177308-0d34-0410-b5e6-96231b3b80d8
The description of the 'returned' attribute says that it is only used when
code-generating the caller. I'd like to make the optimizer smarter about
looking through functions with returned arguments (generally, but motivated by
my llvm.noalias work). As David pointed out in the review of D22202, the
LangRef should be updated to make its expanded uses clearer.
Differential Revision: http://reviews.llvm.org/D22205
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275026 91177308-0d34-0410-b5e6-96231b3b80d8
