Today, we do not allow cmpxchg operations with pointer arguments. We require the frontend to insert ptrtoint casts and do the cmpxchg in integers. While correct, this is problematic from a couple of perspectives:
1) It makes the IR harder to analyse (for instance, it make capture tracking overly conservative)
2) It pushes work onto the frontend authors for no real gain
This patch implements the simplest form of IR support. As we did with floating point loads and stores, we teach AtomicExpand to convert back to the old representation. This prevents us needing to change all backends in a single lock step change. Over time, we can migrate each backend to natively selecting the pointer type. In the meantime, we get the advantages of a cleaner IR representation without waiting for the backend changes.
Differential Revision: http://reviews.llvm.org/D17413
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261281 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
As previously written, only functions could be convergent. But calls
need to have a notion of convergence as well.
To see why this is important, consider an indirect call. We may or may
not want to disable optimizations around it and behave as though we're
calling a convergent function -- it depends on the semantics of the
language we're compiling. Thus the need for this attr on the call.
Reviewers: jingyue, joker.eph
Subscribers: llvm-commits, tra, jhen, arsenm, chandlerc, hfinkel, resistor
Differential Revision: http://reviews.llvm.org/D17314
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261111 91177308-0d34-0410-b5e6-96231b3b80d8
It seems the ARMv8 instruction set overview is no longer provided by ARM, so
I've removed it. Since most of the other documents were the same I unified the
two sections.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@260329 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Be more explicit about what 'convergent' means, and indicate that the
compiler may remove the attribute from a function if it can prove that
the function doesn't in fact execute any convergent ops.
Reviewers: resistor, jingyue, joker.eph
Subscribers: hfinkel, chandlerc, arsenm, jhen, tra, llvm-commits
Differential Revision: http://reviews.llvm.org/D17012
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@260318 91177308-0d34-0410-b5e6-96231b3b80d8
Mehdi suggested in a review of r259766 that it's also useful to easily
set the type of LTO. Augment the cmake variable to support that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@260143 91177308-0d34-0410-b5e6-96231b3b80d8
Watching new contributors trying to build LLVM on Windows, one of the
very common failure modes was getting a version of Visual Studio
that did not have a C++ compiler for CMake to put up. Trying to create
a C++ project in Visual Studio will cause Visual Studio to go and
download the C++ tools.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@260049 91177308-0d34-0410-b5e6-96231b3b80d8
This just incrementally improves what was already there; it's questionable whether this content belongs in the getting started guide at all.
Patch by Ben Nathanson w/permission w/minor edtis by me.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@260040 91177308-0d34-0410-b5e6-96231b3b80d8
The mentioned environment variable doesn't appear to have any use in the LLVM repository. If it is still relevant for clang, we can consider adding it to the clang getting started page.
Patch inspired by documentation work by Ben Nathanson at the LLVM Bloomberg sprint.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@260037 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
When alias analysis is uncertain about the aliasing between any two accesses,
it will return MayAlias. This uncertainty from alias analysis restricts LICM
from proceeding further. In cases where alias analysis is uncertain we might
use loop versioning as an alternative.
Loop Versioning will create a version of the loop with aggressive aliasing
assumptions in addition to the original with conservative (default) aliasing
assumptions. The version of the loop making aggressive aliasing assumptions
will have all the memory accesses marked as no-alias. These two versions of
loop will be preceded by a memory runtime check. This runtime check consists
of bound checks for all unique memory accessed in loop, and it ensures the
lack of memory aliasing. The result of the runtime check determines which of
the loop versions is executed: If the runtime check detects any memory
aliasing, then the original loop is executed. Otherwise, the version with
aggressive aliasing assumptions is used.
The pass is off by default and can be enabled with command line option
-enable-loop-versioning-licm.
Reviewers: hfinkel, anemet, chatur01, reames
Subscribers: MatzeB, grosser, joker.eph, sanjoy, javed.absar, sbaranga,
llvm-commits
Differential Revision: http://reviews.llvm.org/D9151
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259986 91177308-0d34-0410-b5e6-96231b3b80d8
This is the right location for platform-specific files.
On some distributions (e. g. Exherbo), a package can be installed for several
architectures in parallel, but the architecture-independent files are shared.
Therefore, we must not install architecture-dependent files (like the CMake
config and export files) to share/.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259821 91177308-0d34-0410-b5e6-96231b3b80d8
This adds -DLLVM_ENABLE_LTO, rather than forcing people to manually
add -flto to the various _FLAGS variables.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259766 91177308-0d34-0410-b5e6-96231b3b80d8
1. Mentioned that CUDA support works best with trunk.
2. Simplified the example by removing its dependency on the CUDA samples.
3. Explain the --cuda-gpu-arch flag.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259307 91177308-0d34-0410-b5e6-96231b3b80d8