| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 309445
|
| |
|
|
| |
llvm-svn: 309431
|
| |
|
|
|
|
|
|
|
|
|
|
| |
There is no situation where this rarely-used argument cannot be
substituted with a DIExpression and removing it allows us to simplify
the DWARF backend. Note that this patch does not yet remove any of
the newly dead code.
rdar://problem/33580047
Differential Revision: https://reviews.llvm.org/D35951
llvm-svn: 309426
|
| |
|
|
| |
llvm-svn: 309117
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: dgross
Reviewed By: dgross
Subscribers: dgross, llvm-commits
Differential Revision: https://reviews.llvm.org/D35822
llvm-svn: 308994
|
| |
|
|
| |
llvm-svn: 308541
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Describe:
+ Exact tablegen command and how to get it
+ tablegen command debug option for subtarget generation
+ Use of schedcover.py on the debug output to determine coverage
Differential Revision: https://reviews.llvm.org/D35058
llvm-svn: 308476
|
| |
|
|
| |
llvm-svn: 308474
|
| |
|
|
| |
llvm-svn: 308442
|
| |
|
|
| |
llvm-svn: 308331
|
| |
|
|
|
|
|
|
|
| |
objects to start at the same address
As discussed on the ML, there's consensus that this is what the implementations
do and it seems sensible.
llvm-svn: 308090
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Debugging LIT scripts can be rather painful, as LIT directly does not
specify which line has failed.
Rather, FileCheck is expected to report the failing location, but it can
be often ambiguous if multiple commands are tested against the same
prefix. This change adds a -vv option, which echoes all output.
Then detecting the error becomes straightforward: last printed line is
the failing one.
Of course, it could be desired to try to get failing line number
directly from bash, but it involves excessive hacks on older bash
versions (cf.
https://stackoverflow.com/questions/24398691/how-to-get-the-real-line-number-of-a-failing-bash-command)
Differential Revision: https://reviews.llvm.org/D35330
llvm-svn: 307938
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Continuing the work from https://reviews.llvm.org/D33240, this change introduces an element unordered-atomic memset intrinsic. This intrinsic is essentially memset with the implementation requirement that all stores used for the assignment are done with unordered-atomic stores of a given element size.
Reviewers: eli.friedman, reames, mkazantsev, skatkov
Reviewed By: reames
Subscribers: jfb, dschuff, sbc100, jgravelle-google, aheejin, efriedma, llvm-commits
Differential Revision: https://reviews.llvm.org/D34885
llvm-svn: 307854
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Continuing the work from https://reviews.llvm.org/D33240, this change introduces an element unordered-atomic memmove intrinsic. This intrinsic is essentially memmove with the implementation requirement that all loads/stores used for the copy are done with unordered-atomic loads/stores of a given element size.
Reviewers: eli.friedman, reames, mkazantsev, skatkov
Reviewed By: reames
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34884
llvm-svn: 307796
|
| |
|
|
| |
llvm-svn: 307775
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OpenCL 2.0 introduces the notion of memory scopes in atomic operations to
global and local memory. These scopes restrict how synchronization is
achieved, which can result in improved performance.
This change extends existing notion of synchronization scopes in LLVM to
support arbitrary scopes expressed as target-specific strings, in addition to
the already defined scopes (single thread, system).
The LLVM IR and MIR syntax for expressing synchronization scopes has changed
to use *syncscope("<scope>")*, where <scope> can be "singlethread" (this
replaces *singlethread* keyword), or a target-specific name. As before, if
the scope is not specified, it defaults to CrossThread/System scope.
Implementation details:
- Mapping from synchronization scope name/string to synchronization scope id
is stored in LLVM context;
- CrossThread/System and SingleThread scopes are pre-defined to efficiently
check for known scopes without comparing strings;
- Synchronization scope names are stored in SYNC_SCOPE_NAMES_BLOCK in
the bitcode.
Differential Revision: https://reviews.llvm.org/D21723
llvm-svn: 307722
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D35155
llvm-svn: 307702
|
| |
|
|
|
|
|
|
|
|
| |
When an output directory is specified, llvm-cov spawns some threads to
speed up the process of writing out file reports. Add an option which
allows users to control how many threads llvm-cov uses.
A CommandGuide.rst update + test is included.
llvm-svn: 307609
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D35023
llvm-svn: 307568
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: beanz, mehdi_amini
Reviewed By: beanz
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D35080
llvm-svn: 307560
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
r274441 introduced Chapter 10 of "Implementing a Language with LLVM" tutorial,
which caused all files in the tutorial to start using two digit numbering. But
many links were not changed and therefore appear to be broken. This patch
addresses described issue.
As a result, following command does not produce any output anymore:
$ grep -nR '<LangImpl[0-9].html>' ./docs/tutorial/
llvm-svn: 307525
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D33736
llvm-svn: 307353
|
| |
|
|
|
|
|
|
|
| |
This is especially useful when lit is invoked indirectly by the build
system, and additional arguments can not be easily specified.
Differential Revision: https://reviews.llvm.org/D35091
llvm-svn: 307339
|
| |
|
|
| |
llvm-svn: 307299
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- Removed double indirection via command-line args (i.e. two `--`
options of `build_docker_image.sh`).
- Added a comment on how to build 2-stage clang install into the
`build_docker_image.sh`, it used to be only in the `docs/Docker.rst`.
Reviewers: klimek, mehdi_amini
Reviewed By: klimek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35050
llvm-svn: 307256
|
| |
|
|
| |
llvm-svn: 307200
|
| |
|
|
| |
llvm-svn: 306975
|
| |
|
|
|
|
|
|
|
|
| |
Working with git on a branch I find it really annoying that committing
a change causes ninja to think that stuff needs to be rebuilt.
With this change at least nothing in llvm needs to be rebuild when
something is committed.
llvm-svn: 306858
|
| |
|
|
| |
llvm-svn: 306811
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: klimek, chandlerc, mehdi_amini
Reviewed By: klimek, mehdi_amini
Subscribers: mehdi_amini, jlebar, llvm-commits
Differential Revision: https://reviews.llvm.org/D34197
llvm-svn: 306810
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
It served us well, helped kick-start much of the vectorization efforts
in LLVM, etc. Its time has come and past. Back in 2014:
http://lists.llvm.org/pipermail/llvm-dev/2014-November/079091.html
Time to actually let go and move forward. =]
I've updated the release notes both about the removal and the
deprecation of the corresponding C API.
llvm-svn: 306797
|
| |
|
|
| |
llvm-svn: 306777
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D34668
llvm-svn: 306718
|
| |
|
|
| |
llvm-svn: 306262
|
| |
|
|
| |
llvm-svn: 306223
|
| |
|
|
| |
llvm-svn: 306222
|
| |
|
|
|
|
|
|
| |
this in docs
PR#32760
llvm-svn: 306102
|
| |
|
|
|
|
|
|
|
|
| |
Also document the attribute, since "probe-stack" already is.
Reviewed By: majnemer
Differential Revision: https://reviews.llvm.org/D34528
llvm-svn: 306069
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This attribute is used to ensure the guard page is triggered on stack
overflow. Stack frames larger than the guard page size will generate
a call to __probestack to touch each page so the guard page won't
be skipped.
Reviewed By: majnemer
Differential Revision: https://reviews.llvm.org/D34386
llvm-svn: 305939
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Section "Arguments" of `getelementptr` [1] says the first argument is a
type, the second argument is a pointer or a vector of pointers, and is
the base address to start from. Update `getelementptr` FAQ [2]
accordingly, based on discussion with David on the mailing list [3].
[1] http://llvm.org/docs/LangRef.html#getelementptr-instruction
[2] http://llvm.org/docs/GetElementPtr.html
[3] http://lists.llvm.org/pipermail/llvm-dev/2017-June/114294.html
Patch by Wei-Ren Chen!
Differential Revision: https://reviews.llvm.org/D34325
llvm-svn: 305662
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Background: http://lists.llvm.org/pipermail/llvm-dev/2017-May/112779.html
This change is to alter the prototype for the atomic memcpy intrinsic. The prototype itself is being changed to more closely resemble the semantics and parameters of the llvm.memcpy intrinsic -- to ease later combination of the llvm.memcpy and atomic memcpy intrinsics. Furthermore, the name of the atomic memcpy intrinsic is being changed to make it clear that it is not a generic atomic memcpy, but specifically a memcpy is unordered atomic.
Reviewers: reames, sanjoy, efriedma
Reviewed By: reames
Subscribers: mzolotukhin, anna, llvm-commits, skatkov
Differential Revision: https://reviews.llvm.org/D33240
llvm-svn: 305558
|
| |
|
|
| |
llvm-svn: 305515
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Points to existing documentation for branch_weights and
function_entry_count, and adds an example for VP value profile metadata.
Reviewers: davidxl, reames
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34218
llvm-svn: 305475
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch is part of 3 patches that together form a single patch, but must be introduced in stages in order not to break things.
The way that LLVM interprets DW_OP_plus in DIExpression nodes is basically that of the DW_OP_plus_uconst operator since LLVM expects an unsigned constant operand. This unnecessarily restricts the DW_OP_plus operator, preventing it from being used to describe the evaluation of runtime values on the expression stack. These patches try to align the semantics of DW_OP_plus and DW_OP_minus with that of the DWARF definition, which pops two elements off the expression stack, performs the operation and pushes the result back on the stack.
This is done in three stages:
• The first patch (LLVM) adds support for DW_OP_plus_uconst.
• The second patch (Clang) contains changes all its uses from DW_OP_plus to DW_OP_plus_uconst.
• The third patch (LLVM) changes the semantics of DW_OP_plus and DW_OP_minus to be in line with its DWARF meaning. This patch includes the bitcode upgrade from legacy DIExpressions.
Patch by Sander de Smalen.
Reviewers: echristo, pcc, aprantl
Reviewed By: aprantl
Subscribers: fhahn, javed.absar, aprantl, llvm-commits
Differential Revision: https://reviews.llvm.org/D33894
llvm-svn: 305386
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch is part of 3 patches that together form a single patch, but must be introduced in stages in order not to break things.
The way that LLVM interprets DW_OP_plus in DIExpression nodes is basically that of the DW_OP_plus_uconst operator since LLVM expects an unsigned constant operand. This unnecessarily restricts the DW_OP_plus operator, preventing it from being used to describe the evaluation of runtime values on the expression stack. These patches try to align the semantics of DW_OP_plus and DW_OP_minus with that of the DWARF definition, which pops two elements off the expression stack, performs the operation and pushes the result back on the stack.
This is done in three stages:
• The first patch (LLVM) adds support for DW_OP_plus_uconst.
• The second patch (Clang) contains changes all its uses from DW_OP_plus to DW_OP_plus_uconst.
• The third patch (LLVM) changes the semantics of DW_OP_plus and DW_OP_minus to be in line with its DWARF meaning. This patch includes the bitcode upgrade from legacy DIExpressions.
Patch by Sander de Smalen.
Reviewers: pcc, echristo, aprantl
Reviewed By: aprantl
Subscribers: fhahn, aprantl, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D33892
llvm-svn: 305304
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add a lexicon entry for global value numbering.
Reviewers: davide, majnemer
Reviewed By: davide
Subscribers: llvm-commits, inouehrs
Differential Revision: https://reviews.llvm.org/D33664
llvm-svn: 305270
|
| |
|
|
|
|
| |
And reverse the ownership between DICompileUnit and DISubprogram.
llvm-svn: 305254
|
| |
|
|
|
|
|
|
|
|
| |
named metadata.
The new metadata is easier to manipulate than module flags.
Differential Revision: https://reviews.llvm.org/D31349
llvm-svn: 305227
|
| |
|
|
|
|
|
|
|
|
| |
This is to reflect the evolving nature of the tool as being
useful for more than just dumping PDBs, as it can do many other
things.
Differential Revision: https://reviews.llvm.org/D34062
llvm-svn: 305106
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D34001
llvm-svn: 304995
|