Rather than copying the file and then doing an in-place edit, perform the
replacements to stdout and pass the output to FileCheck directly. Avoids
unnecessary copying and seds.
llvm-svn: 276836
Make integers explicitly unsigned, so the tuple constructor will resolve
properly when but with clang 3.6, 3.7 and gcc 6.1.1 libstdc++ headers.
Patch by Frederich Munch!
Differential Revision: https://reviews.llvm.org/D22798
llvm-svn: 276831
Summary:
To build llgo, you must currently ensure that llgo
is in the tools/llgo directory, due to a hard-coded
path in llvm-go.
To support the use of LLVM_EXTERNAL_LLGO_SOURCE_DIR,
we introduce a flag to llvm-go that enables the
caller to specify the paths to symlink in the
temporary $GOPATH.
Reviewers: pcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D21634
llvm-svn: 276829
Summary:
To support the use of LLVM_EXTERNAL_LLGO_SOURCE_DIR,
with llgo situated in a location other than tools/llgo,
we add the llgo source directory to LLVM_GO_PACKAGES.
Reviewers: pcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D21635
llvm-svn: 276828
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
llvm-svn: 276818
Change the syntax to use `%0.sub8` to denote a subregister.
This seems like a more natural fit to denote subregisters; I also plan
to introduce a new ":classname" syntax in upcoming patches to denote the
register class of a vreg.
Note that this commit disallows plain identifiers to start with a '.'
character. This shouldn't affect anything as external names/IR
references are all prefixed with '$'/'%', plain identifiers are only
used for instruction names, register mask names and subreg indexes.
Differential Revision: https://reviews.llvm.org/D22390
llvm-svn: 276815
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
llvm-svn: 276813
We already have code for ARM in initializeSections, so this
is more consistent.
Differential Revision: https://reviews.llvm.org/D22833
llvm-svn: 276811
Summary:
s/code-block:: C++/code-block:: c++ in docs/Coroutines.rst .
Patch by Gor Nishanov! Edited by Sanjoy to fix a missing s/C/c/.
Reviewers: sanjoy, rengolin
Differential Revision: https://reviews.llvm.org/D22832
llvm-svn: 276806
The kernel on Nexus 5X returns error_code in ucontext which has
correct FSR_WRITE flag, but empty (zero) abort type field. Removing
the checks means that we will report all SEGVs as READ on very old
kernels, but will properly distinguish READ vs WRITE on moderately
old ones.
llvm-svn: 276803
We were just checking the public state, but that meant if you were hung in a long
running hand-called function, we wouldn't know to interrupt the process, and we would
not succeed in killing it.
<rdar://problem/24805082>
llvm-svn: 276795
Consider this case:
vreg1 = A2_zxth vreg0 (1)
...
vreg2 = A2_zxth vreg1 (2)
Redundant instruction elimination could delete the instruction (1)
because the user (2) only cares about the low 16 bits. Then it could
delete (2) because the input is already zero-extended. The problem
is that the properties allowing each individual instruction to be
deleted depend on the existence of the other instruction, so either
one can be deleted, but not both.
The existing check for this situation in RIE was insufficient. The
fix is to update all dependent cells when an instruction is removed
(replaced via COPY) in RIE.
llvm-svn: 276792