| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 292752
|
|
|
|
| |
llvm-svn: 292657
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Docs for clang::Decl and clang::TemplateSpecializationType have
not been generated since LLVM_ALIGNAS was added to them.
Tell Doxygen to expand LLVM_ALIGNAS to nothing as described at
https://www.stack.nl/~dimitri/doxygen/manual/preprocessing.html
Reviewers: aaron.ballman, klimek, alexfh
Subscribers: ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D28850
llvm-svn: 292483
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change equips lit.py with two new options, --num-shards=M and
--run-shard=N (set by default from env vars LIT_NUM_SHARDS and LIT_RUN_SHARD).
The options must be used together, and N must be in 1..M.
Together these options effect only test selection: they partition the testsuite
into M equal-sized "shards", then select only the Nth shard. They can be used
in a cluster of test machines to achieve a very crude (static) form of
parallelism, with minimal configuration work.
Reviewers: modocache, ddunbar
Reviewed By: ddunbar
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28789
llvm-svn: 292417
|
|
|
|
| |
llvm-svn: 292318
|
|
|
|
|
|
|
|
|
| |
LLVM_ENABLE_PROJECTS works on linux
I tested the previous one on macOS, however building libc++ on Linux
requires libcxxabi as well.
llvm-svn: 292290
|
|
|
|
|
|
| |
builder back to green (http://lab.llvm.org:8011/builders/llvm-sphinx-docs/builds/1895).
llvm-svn: 292271
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes:
Warning, treated as error:
/home/buildbot/llvm-build-dir/llvm-sphinx-docs/llvm/src/docs/NVPTXUsage.rst:333:
ERROR: Error in "code-block" directive:
maximum 1 argument(s) allowed, 17 supplied.
llvm-svn: 292148
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously there were three ways to inform the NVVMReflect pass whether
you wanted to flush denormals to zero:
* An LLVM command-line option
* Parameters to the NVVMReflect constructor
* Metadata on the module itself.
This change removes the first two, leaving only the third.
The motivation for this change, aside from simplifying things, is that
we want LLVM to be aware of whether it's operating in FTZ mode, so other
passes can use this information. Ideally we'd have a target-generic
piece of metadata on the module. This change moves us in that
direction.
Reviewers: tra
Subscribers: jholewinski, llvm-commits
Differential Revision: https://reviews.llvm.org/D28700
llvm-svn: 292068
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This string parameter is passed to -fuse-ld when linking. It can be
an absolute path to your custom linker, otherwise clang will look for
`ld.{name}`.
Reviewers: davide, tejohnson, pcc
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28738
llvm-svn: 292047
|
|
|
|
| |
llvm-svn: 292014
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D28687
llvm-svn: 291948
|
|
|
|
| |
llvm-svn: 291836
|
|
|
|
| |
llvm-svn: 291815
|
|
|
|
|
|
|
|
| |
This is already documented on the call instruction, but
not in the list of supported instructions in the fast math
flag section.
llvm-svn: 291578
|
|
|
|
|
|
|
|
| |
Subscribers: cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D28326
llvm-svn: 291139
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Test commit, fix minor grammatical error in Phabricator.rst
Reviewers: delcypher
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28214
llvm-svn: 291101
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add an explicit LLVM_ENABLE_DIA_SDK option to control building support
for DIA SDK-based debugging. Control its value to match whether DIA SDK
support was found and expose it in LLVMConfig (alike LLVM_ENABLE_ZLIB).
Its value is needed for LLDB to determine whether to run tests requiring
DIA support. Currently it is obtained from llvm/Config/config.h;
however, this file is not available for standalone builds. Following
this change, LLDB will be modified to use the value from LLVMConfig.
Differential Revision: https://reviews.llvm.org/D26255
llvm-svn: 290818
|
|
|
|
|
|
|
| |
This reapplies rL289013 (reverted in rL289014) with the fixes identified
in D21731. Should hopefully pass the buildbots this time.
llvm-svn: 290809
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Update the Phabricator docs to clarify how changes are merged for contributors without commit access.
Reviewers: delcypher, aaron.ballman
Subscribers: aaron.ballman, anmol, llvm-commits
Differential Revision: https://reviews.llvm.org/D28184
llvm-svn: 290767
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
gep 0, 0 is equivalent to bitcast. LLVM canonicalizes it
to getelementptr because it make SROA can then handle it.
Simple case like
void g(A &a) {
z(a);
if (glob)
a.foo();
}
void testG() {
A a;
g(a);
}
was not devirtualized with -fstrict-vtable-pointers because luck of
handling for gep 0 in Memory Dependence Analysis
Reviewers: dberlin, nlewycky, chandlerc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28126
llvm-svn: 290763
|
|
|
|
| |
llvm-svn: 290709
|
|
|
|
|
|
|
|
|
|
| |
This change adds a new intrinsic which is intended to provide memcpy functionality
with additional atomicity guarantees. Please refer to the review thread
or language reference for further details.
Differential Revision: https://reviews.llvm.org/D27133
llvm-svn: 290708
|
|
|
|
|
|
|
|
| |
and RelWithDebInfo in Cmake.rst
This is surprising to many people.
llvm-svn: 290556
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D27642
llvm-svn: 290514
|
|
|
|
| |
llvm-svn: 290501
|
|
|
|
| |
llvm-svn: 290187
|
|
|
|
| |
llvm-svn: 290186
|
|
|
|
|
|
|
| |
This creates non-linear behavior in the inliner (see more details in
r289755's commit thread).
llvm-svn: 290086
|
|
|
|
|
|
|
|
| |
MSVC 2015 has been the minimum supported version of VS since October.
Differential Revision: https://reviews.llvm.org/D25710
llvm-svn: 289854
|
|
|
|
| |
llvm-svn: 289849
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This replaces the format member search, which was quite complicated, with a more
direct approach to detecting whether a class should be formatted using the
format-member method. Instead we use a special type llvm::format_adapter, which
every adapter must inherit from. Then the search can be simply implemented with
the is_base_of type trait.
Aside from the simplification, I like this way more because it makes it more
explicit that you are supposed to use this type only for adapter-like
formattings, and the other approach (format_provider overloads) should be used
as a default (a mistake I made when first trying to use this library).
The only slight change in behaviour here is that now choose the format-adapter
branch even if the format member invocation will fail to compile (e.g. because it is a
non-const member function and we are passing a const adapter), whereas
previously we would have gone on to search for format_providers for the type.
However, I think that is actually a good thing, as it probably means the
programmer did something wrong.
Reviewers: zturner, inglorion
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D27679
llvm-svn: 289795
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was an efficiency problem with how we processed @llvm.assume in
ValueTracking (and other places). The AssumptionCache tracked all of the
assumptions in a given function. In order to find assumptions relevant to
computing known bits, etc. we searched every assumption in the function. For
ValueTracking, that means that we did O(#assumes * #values) work in InstCombine
and other passes (with a constant factor that can be quite large because we'd
repeat this search at every level of recursion of the analysis).
Several of us discussed this situation at the last developers' meeting, and
this implements the discussed solution: Make the values that an assume might
affect operands of the assume itself. To avoid exposing this detail to
frontends and passes that need not worry about it, I've used the new
operand-bundle feature to add these extra call "operands" in a way that does
not affect the intrinsic's signature. I think this solution is relatively
clean. InstCombine adds these extra operands based on what ValueTracking, LVI,
etc. will need and then those passes need only search the users of the values
under consideration. This should fix the computational-complexity problem.
At this point, no passes depend on the AssumptionCache, and so I'll remove
that as a follow-up change.
Differential Revision: https://reviews.llvm.org/D27259
llvm-svn: 289755
|
|
|
|
| |
llvm-svn: 289622
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Attaching !absolute_symbol to a global variable does two things:
1) Marks it as an absolute symbol reference.
2) Specifies the value range of that symbol's address.
Teach the X86 backend to allow absolute symbols to appear in place of
immediates by extending the relocImm and mov64imm32 matchers. Start using
relocImm in more places where it is legal.
As previously proposed on llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2016-October/105800.html
Differential Revision: https://reviews.llvm.org/D25878
llvm-svn: 289087
|
|
|
|
|
|
| |
Appears to break on build bots. Reverting pending investigation.
llvm-svn: 289014
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The relocations for `DIEEntry::EmitValue` were wrong for Win64
(emitting FK_Data_4 instead of FK_SecRel_4). This corrects that
oversight so that the DWARF data is correct in Win64 COFF files.
Fixes PR15393.
Patch by Jameson Nash <jameson@juliacomputing.com> based on a patch
by David Majnemer.
Differential Revision: https://reviews.llvm.org/D21731
llvm-svn: 289013
|
|
|
|
| |
llvm-svn: 288562
|
|
|
|
|
|
|
|
|
|
| |
Now that PointerType is no longer a SequentialType, all SequentialTypes
have an associated number of elements, so we can move that information to
the base class, allowing for a number of simplifications.
Differential Revision: https://reviews.llvm.org/D27122
llvm-svn: 288464
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As proposed on llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2016-October/106640.html
This is for a couple of reasons:
- Values of type PointerType are unlike the other SequentialTypes (arrays
and vectors) in that they do not hold values of the element type. By moving
PointerType we can unify certain aspects of how the other SequentialTypes
are handled.
- PointerType will have no place in the SequentialType hierarchy once
pointee types are removed, so this is a necessary step towards removing
pointee types.
Differential Revision: https://reviews.llvm.org/D26595
llvm-svn: 288462
|
|
|
|
| |
llvm-svn: 288233
|
|
|
|
| |
llvm-svn: 288232
|
|
|
|
| |
llvm-svn: 288205
|
|
|
|
|
|
|
|
|
|
| |
While reading the LTO docs I fixed few small typos and whitespace issues.
Patch by: Jonas Devlieghere <jonas@devlieghere.com>
Differential Revision: https://reviews.llvm.org/D27196
llvm-svn: 288171
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The return type is `iN` rather than always `i16`
Seems to be a typo in https://reviews.llvm.org/rL252878 .
Reviewers: jmolloy
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D27047
llvm-svn: 287769
|
|
|
|
|
|
| |
-lcudart_static doesn't work. We don't know why.
llvm-svn: 287715
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previously used "names" are rather descriptions (they use multiple
words and contain spaces), use short programming language identifier
like strings for the "names" which should be used when exporting to
machine parseable formats.
Also removed a unused TimerGroup from Hexxagon.
Differential Revision: https://reviews.llvm.org/D25583
llvm-svn: 287369
|
|
|
|
|
|
| |
doesn't and hasn't for at least 9 years.
llvm-svn: 287299
|
|
|
|
| |
llvm-svn: 287290
|
|
|
|
| |
llvm-svn: 287289
|