| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The project has been renamed to Acxxel, so this old directory needs to
be deleted.
Reviewers: jlebar, jprice
Subscribers: beanz, mgorny, parallel_libs-commits, modocache
Differential Revision: https://reviews.llvm.org/D25964
llvm-svn: 285115
|
|
|
|
|
|
|
|
| |
commands the continue the process.
This closes https://reviews.llvm.org/D25875.
llvm-svn: 285114
|
|
|
|
| |
llvm-svn: 285113
|
|
|
|
| |
llvm-svn: 285112
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Acxxel is basically a simplified redesign of StreamExecutor.
Here are the major points where Acxxel differs from the current
StreamExecutor design:
* Acxxel doesn't support the kernel and kernel loader types designed for
emission by the compiler to support type-safe kernel launches. For
CUDA, kernels in Acxxel can be seamlessly launched using the standard
CUDA triple-chevron kernel launch syntax that is available with clang
and nvcc. For CUDA and OpenCL, kernel arguments can be passed in the
old-fashioned way, as one array of pointers to arguments and another
array of argument sizes. Although OpenCL doesn't get a type-safe
kernel launch method, it does still get the benefit of all the memory
management wrappers. In the future, clang may add support for
triple-chevron OpenCL kernel launchs, or some other type-safe OpenCL
kernel launch method.
* Acxxel does not depend on any other code in LLVM, so it builds
completely independently from LLVM.
The goal will be to check in Acxxel and remove StreamExecutor, or
perhaps to remove the old StreamExecutor and rename Acxxel to
StreamExecutor, so I think Acxxel should be thought of as a new version
of StreamExecutor, not as a separate project.
Reviewers: jlebar, jprice
Subscribers: beanz, mgorny, modocache, parallel_libs-commits
Differential Revision: https://reviews.llvm.org/D25701
llvm-svn: 285111
|
|
|
|
|
|
|
|
| |
This reverts r285093, as it caused unexpected buildbot failures on
clang-ppc64le-linux, clang-ppc64be-linux, clang-ppc64be-linux-multistage
and clang-ppc64be-linux-lnt. Failing test ubsan/TestCases/TypeCheck/vptr.cpp.
llvm-svn: 285110
|
|
|
|
|
|
| |
desired bytes. Add another test for use_cmp
llvm-svn: 285109
|
|
|
|
|
|
|
|
|
|
| |
Fixes the FIXMEs in D25952 and rL285075.
Patch by bryant!
Differential Revision: https://reviews.llvm.org/D25955
llvm-svn: 285108
|
|
|
|
| |
llvm-svn: 285107
|
|
|
|
|
|
| |
Modify the maximum jump table size.
llvm-svn: 285106
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The intention is to make APFloat an interface class, so that later I can add a second implementation class DoubleAPFloat to correctly implement PPCDoubleDouble semantic. The interface of IEEEFloat is not public, and can be simplified (currently it's exactly the same as the old APFloat), but that belongs to a separate patch.
DoubleAPFloat should look like:
class DoubleAPFloat {
const fltSemantics *Semantics;
std::unique_ptr<APFloat> APFloats; // Two heap-allocated APFloats.
};
There is no functional change, nor public interface change.
Reviewers: hfinkel, chandlerc, iteratee, echristo, kbarton
Subscribers: llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D25536
llvm-svn: 285105
|
|
|
|
|
|
|
|
|
|
| |
Add an option to allow easier experimentation by target maintainers with the
minimum number of entries to create jump tables. Also clarify the name of
the other existing option governing the creation of jump tables.
Differential revision: https://reviews.llvm.org/D25883
llvm-svn: 285104
|
|
|
|
|
|
|
|
|
| |
CodeCoverageTool::error() depends on CoverageViewOptions::Colors being
initialized. Should fix:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/56
llvm-svn: 285103
|
|
|
|
| |
llvm-svn: 285102
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
definitions from the dylib
Summary:
This patch turns on `-fvisibility-inlines-hidden` when building the dylib. This is important so that libc++.dylib doesn't accidentally export inline-functions which are ODR used somewhere in the dylib.
On OS X this change has no effect on the current ABI of the dylib. Unfortunately on Linux there are already ~20 inline functions which are unintentionally exported by the dylib. Almost all of these are implicitly generated destructors. I believe removing these function definitions is safe because every "linkage unit" which uses these functions has its own definition, and therefore shouldn't be dependent on libc++.dylib to provide them.
Also could a FreeBSD maintainer comment on the ABI compatibility of this patch?
Reviewers: mclow.lists, emaste, dexonsmith, joker-eph-DISABLED, jroelofs, danalbert, mehdi_amini, compnerd, dim
Subscribers: beanz, mgorny, cfe-commits, modocache
Differential Revision: https://reviews.llvm.org/D25593
llvm-svn: 285101
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
`__libcpp_refstring` currently has two different definitions. First there is the complete definition in `<__refstring>` but there is also a second in `<stdexcept>`. The historical reason for this split is because both libc++ and libc++abi need to see the inline definitions of __libcpp_refstrings methods, but the `<stdexcept>` header doesn't. However this is an ODR violation and breaks the modules build.
This patch fixes the issue by creating a single class definition in `<stdexcept>` and changing `<__refstring>` to contain only the inline method definitions. This way both `libcxx/src/stdexcept.cpp` and `libcxxabi/src/stdexcept.cpp` see the same declaration in `<stdexcept>` and definitions in `<__refstring>`
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25603
llvm-svn: 285100
|
|
|
|
|
|
|
|
|
|
|
| |
When there's a tie between partitionings of jump tables, consider also cases
that result in no jump tables, but in one or a few cases. The motivation is
that many contemporary processors typically perform case switches fairly
quickly.
Differential revision: https://reviews.llvm.org/D25212
llvm-svn: 285099
|
|
|
|
|
|
|
|
| |
The problem with the original commit was that some of Apple's headers depended
on an incorrect behaviour, this commit adds a temporary workaround until those
headers are fixed.
llvm-svn: 285098
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we predicate an instruction (div, rem, store) we place the instruction in
its own basic block within the vectorized loop. If a predicated instruction has
scalar operands, it's possible to recursively sink these scalar expressions
into the predicated block so that they might avoid execution. This patch sinks
as much scalar computation as possible into predicated blocks. We previously
were able to sink such operands only if they were extractelement instructions.
Differential Revision: https://reviews.llvm.org/D25632
llvm-svn: 285097
|
|
|
|
| |
llvm-svn: 285096
|
|
|
|
|
|
|
|
| |
Patch by bryant!
Differential Revision: https://reviews.llvm.org/D25952
llvm-svn: 285095
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a new function to DebugInfo.cpp that takes an llvm::Module
as input and removes all debug info metadata that is not directly
needed for line tables, thus effectively stripping all type and
variable information from the module.
The primary motivation for this feature was the bitcode work flow
(cf. http://lists.llvm.org/pipermail/llvm-dev/2016-June/100643.html
for more background). This is not wired up yet, but will be in
subsequent patches. For testing, the new functionality is exposed to
opt with a -strip-nonlinetable-debuginfo option.
The secondary use-case (and one that works right now!) is as a
reduction pass in bugpoint. I added two new bugpoint options
(-disable-strip-debuginfo and -disable-strip-debug-types) to control
the new features. By default it will first attempt to remove all debug
information, then only the type info, and then proceed to hack at any
remaining MDNodes.
Thanks to Adrian Prantl for stewarding this patch!
llvm-svn: 285094
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The branch folding pass tail merges blocks into a common-tail. However, the
tail retains the debug information from one of the original inputs to the
merge (chosen randomly). This is a problem for sampled-based PGO, as hits
on the common-tail will be attributed to whichever block was chosen,
irrespective of which path was actually taken to the common-tail.
This patch fixes the issue by nulling the debug location for the common-tail.
Differential Revision: https://reviews.llvm.org/D25742
llvm-svn: 285093
|
|
|
|
| |
llvm-svn: 285092
|
|
|
|
|
|
| |
Let's see what the bots have to say about this...
llvm-svn: 285091
|
|
|
|
|
|
| |
Let's see what the bots have to say about this...
llvm-svn: 285090
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The sanitizer-windows bot turned red with:
FAILED: utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/IntrinsicEmitter.cpp.obj
C:\PROGRA~2\MICROS~1.0\VC\bin\AMD64_~2\cl.exe ... -c
C:\...\llvm\utils\TableGen\IntrinsicEmitter.cpp
c:\...\llvm\utils\tablegen\intrinsicemitter.cpp(254) :
fatal error C1001: An internal error has occurred in the compiler.
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/114/steps/build%20clang%20lld/logs/stdio
llvm-svn: 285089
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D25086
llvm-svn: 285088
|
|
|
|
|
|
|
| |
Things seem to build fine locally without this, so let's
see what the bots think.
llvm-svn: 285087
|
|
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D25931
llvm-svn: 285086
|
|
|
|
|
|
|
| |
call_indirect, grow_memory, and current_memory now have immediate
operands in the 0xd binary encoding.
llvm-svn: 285085
|
|
|
|
| |
llvm-svn: 285084
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
debug loc.
When indvars widened an induction variable, the debug location for the loop
increment computation was incorrectly set equal to the debug loc of the loop
latch terminator.
This patch fixes the issue by propagating the correct location from the
original loop increment instruction to the new widened increment.
Differential Revision: https://reviews.llvm.org/D25872
llvm-svn: 285083
|
|
|
|
| |
llvm-svn: 285082
|
|
|
|
| |
llvm-svn: 285081
|
|
|
|
|
|
|
|
|
|
| |
Now that MemorySSA keeps track of whether MemoryUses are optimized, use
getClobberingMemoryAccess() to check MemoryUse memory dependencies since
it should no longer be so expensive.
This is a follow-up change to https://reviews.llvm.org/D25881
llvm-svn: 285080
|
|
|
|
|
|
|
|
|
|
|
| |
We were fairly inconsistent as to what information should be accessed
with getSectionHdr and what information (like alignment) was stored
elsewhere.
Now all section info has a dedicated getter. The code is also a bit
more compact.
llvm-svn: 285079
|
|
|
|
| |
llvm-svn: 285078
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is not safe to use LOAD ON CONDITION to implement access to a memory
location marked "volatile", since the architecture leaves it unspecified
whether or not an access happens if the condition is false.
The current code already appears to care about that:
def LOC : CondUnaryRSY<"loc", 0xEBF2, nonvolatile_load, GR32, 4>;
Unfortunately, that "nonvolatile_load" operator is simply ignored
by the CondUnaryRSY class, and there was no test to catch it.
llvm-svn: 285077
|
|
|
|
|
|
|
|
|
| |
Disable the OpenSUSE rules for OpenSUSE versions older than 11 as they
are incompatible with the old binutils on that distribution.
Differential Revision: https://reviews.llvm.org/D24954
llvm-svn: 285076
|
|
|
|
|
|
| |
trunc transform
llvm-svn: 285075
|
|
|
|
|
|
|
|
|
|
|
| |
Support using gcc-config to determine the correct GCC toolchain location
on Gentoo. In order to do that, attempt to read gcc-config configuration
form [[sysroot]]/etc/env.d/gcc, if no custom toolchain location is
provided.
Differential Revision: https://reviews.llvm.org/D25661
llvm-svn: 285074
|
|
|
|
|
|
|
|
| |
This allows for the coalescing of the protocol declarations. When the protocols
are declared in headers, multiple definitions of the protocol would be emitted.
Marking them as common data indicates that any one can be selected.
llvm-svn: 285073
|
|
|
|
|
|
|
|
|
|
| |
We already have (V)PMOVZX* combining support, this is the beginning of handling (V)PMOVSX* similarly - other combines in combineVSZext can be generalized in future patches.
This unearthed an interesting bug in that we were generating illegal build vectors on 32-bit targets - it was proving difficult to create a test for it from PMOVZX, but it fired immediately with PMOVSX. I've created a more general form of the existing getConstVector to handle these cases - ideally this should be handled in non-target-specific code but I couldn't find an equivalent.
Differential Revision: https://reviews.llvm.org/D25874
llvm-svn: 285072
|
|
|
|
|
|
|
|
|
|
|
|
| |
When adding an llvm.memcpy instruction to AliasSetTracker, it uses the raw
source and target pointers which preserve bitcasts.
MemAccInst::getPointerOperand() also returns the raw target pointers, but
Scop::buildAliasGroups() did not for the source pointer. This lead to mismatches
between AliasSetTracker and ScopInfo on which pointer to use.
Fixed by also using raw pointers in Scop::buildAliasGroups().
llvm-svn: 285071
|
|
|
|
|
|
| |
Accidentally put in the hoped-for checks ahead of the transform!
llvm-svn: 285070
|
|
|
|
| |
llvm-svn: 285069
|
|
|
|
|
|
|
| |
This reverts commit r284828, as it causes an infinite loop in
TestPrintStackTraces (funnily enough, only when logging is enabled).
llvm-svn: 285068
|
|
|
|
|
|
| |
LLVM_ATTRIBUTE_UNUSED doesn't work for non-gcc style compilers.
llvm-svn: 285067
|
|
|
|
| |
llvm-svn: 285066
|