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
llvm-svn: 261111
Summary: The name is confusing as it matche another method on the module.
Reviewers: joker.eph, Wallbraker, echristo
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17283
llvm-svn: 260920
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.
llvm-svn: 260329
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
llvm-svn: 260318
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.
llvm-svn: 260143
This matches GCC and MSVC's behaviour, and saves on code size.
We were already not extending i1 return values on x86_64 after r127766. This
takes that patch further by applying it to x86 target as well, and also for i8
and i16.
The ABI docs have been unclear about the required behaviour here. The new i386
psABI [1] clearly states (Table 2.4, page 14) that i1, i8, and i16 return
vales do not need to be extended beyond 8 bits. The x86_64 ABI doc is being
updated to say the same [2].
Differential Revision: http://reviews.llvm.org/D16907
[1]. https://01.org/sites/default/files/file_attach/intel386-psabi-1.0.pdf
[2]. https://groups.google.com/d/msg/x86-64-abi/E8O33onbnGQ/_RFWw_ixDQAJ
llvm-svn: 260133
This reduces sizes of instrumented object files, final binaries,
process images, and raw profile data.
The format of the indexed profile data remain the same.
Differential Revision: http://reviews.llvm.org/D16388
llvm-svn: 260117
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.
llvm-svn: 260049
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.
llvm-svn: 260040
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.
llvm-svn: 260037
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
llvm-svn: 259986
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/.
llvm-svn: 259821
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.
llvm-svn: 259307
Add an option to llvm-profdata merge for writing out sparse indexed
profiles. These profiles omit InstrProfRecords for functions which are
never executed.
Differential Revision: http://reviews.llvm.org/D16727
llvm-svn: 259258
I broke the documentation builds when I deleted the MakefileGuide as part of the autoconf removal. At some point I'll need to do a more in-depth pass updating the documentation to remove references to the old build system.
llvm-svn: 258873
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened."
- Obi Wan Kenobi
Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark
Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D16471
llvm-svn: 258861
Adds a way to inspect SHT_GROUP sections in ELF objects.
Displays signature, member sections of these sections.
Differential revision: http://reviews.llvm.org/D16555
llvm-svn: 258845
Summary:
This adds a new kind of operand bundle to LLVM denoted by the
`"gc-transition"` tag. Inputs to `"gc-transition"` operand bundle are
lowered into the "transition args" section of `gc.statepoint` by
`RewriteStatepointsForGC`.
This removes the last bit of functionality that was unsupported in the
deopt bundle based code path in `RewriteStatepointsForGC`.
Reviewers: pgavlin, JosephTremoulet, reames
Subscribers: sanjoy, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D16342
llvm-svn: 258338
Summary:
Document the LLVM_BUILD_LLVM_DYLIB and LLVM_LINK_LLVM_DYLIB
CMake options, move BUILD_SHARED_LIBS out of frequently-used,
and add a note/warning to BUILD_SHARED_LIBS.
Reviewers: beanz, delcypher, mjacob
Subscribers: mjacob, llvm-commits
Differential Revision: http://reviews.llvm.org/D16208
llvm-svn: 257864
The previous text was hard to understand even for me and I wrote it. Hopefully the new structure makes it a bit more clear what's going on. If anyone has word smithing suggestion or clarification questions, please let me know.
llvm-svn: 257847
