summaryrefslogtreecommitdiffstats
path: root/llvm/docs
Commit message (Collapse)AuthorAgeFilesLines
* Document the LLVM_ENABLE_EXPENSIVE_CHECKS cmake option introduced in r268050Simon Pilgrim2016-05-011-0/+3
| | | | llvm-svn: 268197
* [LowerGuardIntrinsics] Keep track of !make.implicit metadataSanjoy Das2016-04-301-1/+6
| | | | | | | | | | If a guard call being lowered by LowerGuardIntrinsics has the `!make.implicit` metadata attached, then reattach the metadata to the branch in the resulting expanded form of the intrinsic. This allows us to implement null checks as guards and still get the benefit of implicit null checks. llvm-svn: 268148
* [Docs] Refer to the CMakePrimer from CMake docChris Bieneman2016-04-291-0/+4
| | | | | | The "Building LLVM with CMake" document should have a reference to the CMakePrimer. llvm-svn: 268109
* [Docs] Add CMake Primer documentChris Bieneman2016-04-292-0/+466
| | | | | | | | This document is intended to provide a basic overview of the CMake scripting language for LLVM developers. It was unorthodoxly reviewed for accuracy and content on the CMake developer list: http://public.kitware.com/pipermail/cmake-developers/2016-April/028300.html llvm-svn: 268096
* [libFuzzer] fix docsKostya Serebryany2016-04-291-3/+3
| | | | llvm-svn: 268092
* [libFuzzer] enable detect_leaks=1, add proper docsKostya Serebryany2016-04-291-11/+22
| | | | llvm-svn: 268088
* Remove stale documentation on -no-aaSanjoy Das2016-04-291-8/+0
| | | | | | The pass itself was removed in rL247167. llvm-svn: 267978
* [libFuzzer] Improve documentationKostya Serebryany2016-04-281-155/+390
| | | | | | | | | | Reviewers: kcc Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D19585 llvm-svn: 267892
* Fixed sphinx warning from r267672Adam Nemet2016-04-271-1/+1
| | | | llvm-svn: 267675
* [LoopDist] Add llvm.loop.distribute.enable loop metadataAdam Nemet2016-04-271-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: D19403 adds a new pragma for loop distribution. This change adds support for the corresponding metadata that the pragma is translated to by the FE. As part of this I had to rethink the flag -enable-loop-distribute. My goal was to be backward compatible with the existing behavior: A1. pass is off by default from the optimization pipeline unless -enable-loop-distribute is specified A2. pass is on when invoked directly from opt (e.g. for unit-testing) The new pragma/metadata overrides these defaults so the new behavior is: B1. A1 + enable distribution for individual loop with the pragma/metadata B2. A2 + disable distribution for individual loop with the pragma/metadata The default value whether the pass is on or off comes from the initiator of the pass. From the PassManagerBuilder the default is off, from opt it's on. I moved -enable-loop-distribute under the pass. If the flag is specified it overrides the default from above. Then the pragma/metadata can further modifies this per loop. As a side-effect, we can now also use -enable-loop-distribute=0 from opt to emulate the default from the optimization pipeline. So to be precise this is the new behavior: C1. pass is off by default from the optimization pipeline unless -enable-loop-distribute or the pragma/metadata enables it C2. pass is on when invoked directly from opt unless -enable-loop-distribute=0 or the pragma/metadata disables it Reviewers: hfinkel Subscribers: joker.eph, mzolotukhin, llvm-commits Differential Revision: http://reviews.llvm.org/D19431 llvm-svn: 267672
* [Docs] Try to clarify the concept of domains for noalias scopeAdam Nemet2016-04-271-1/+9
| | | | | | | | | | | | | | | Summary: This tries to anchor down the concept of domains a bit better. I had trouble initially relating this to anything. Also talking to David Majnemer on IRC suggested that I wasn't the only one. Reviewers: hfinkel Subscribers: llvm-commits, majnemer Differential Revision: http://reviews.llvm.org/D18799 llvm-svn: 267647
* [ppc64] Reenable sibling call optimization on ppc64 since fixed tsan library ↵Chuang-Yu Cheng2016-04-261-0/+1
| | | | | | | | | | | tail-call issue print-stack-trace.cc test failure of compiler-rt has been fixed by r266869 (http://reviews.llvm.org/D19148), so reenable sibling call optimization on ppc64 Reviewers: nemanjai kbarton llvm-svn: 267527
* [LoopVectorize] Don't consider conditional-load dereferenceability for ↵Hal Finkel2016-04-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | marked parallel loops I really thought we were doing this already, but we were not. Given this input: void Test(int *res, int *c, int *d, int *p) { for (int i = 0; i < 16; i++) res[i] = (p[i] == 0) ? res[i] : res[i] + d[i]; } we did not vectorize the loop. Even with "assume_safety" the check that we don't if-convert conditionally-executed loads (to protect against data-dependent deferenceability) was not elided. One subtlety: As implemented, it will still prefer to use a masked-load instrinsic (given target support) over the speculated load. The choice here seems architecture specific; the best option depends on how expensive the masked load is compared to a regular load. Ideally, using the masked load still reduces unnecessary memory traffic, and so should be preferred. If we'd rather do it the other way, flipping the order of the checks is easy. The LangRef is updated to make explicit that llvm.mem.parallel_loop_access also implies that if conversion is okay. Differential Revision: http://reviews.llvm.org/D19512 llvm-svn: 267514
* DebugInfo: Remove MDString-based type referencesDuncan P. N. Exon Smith2016-04-231-11/+15
| | | | | | | | | | | | | | | | | | | | | | | | Eliminate DITypeIdentifierMap and make DITypeRef a thin wrapper around DIType*. It is no longer legal to refer to a DICompositeType by its 'identifier:', and DIBuilder no longer retains all types with an 'identifier:' automatically. Aside from the bitcode upgrade, this is mainly removing logic to resolve an MDString-based reference to an actualy DIType. The commits leading up to this have made the implicit type map in DICompileUnit's 'retainedTypes:' field superfluous. This does not remove DITypeRef, DIScopeRef, DINodeRef, and DITypeRefArray, or stop using them in DI-related metadata. Although as of this commit they aren't serving a useful purpose, there are patchces under review to reuse them for CodeView support. The tests in LLVM were updated with deref-typerefs.sh, which is attached to the thread "[RFC] Lazy-loading of debug info metadata": http://lists.llvm.org/pipermail/llvm-dev/2016-April/098318.html llvm-svn: 267296
* Add some release notes about the fix for PR26774Sanjoy Das2016-04-221-0/+10
| | | | | | As suggested by Chandler on the review thread for D18634. llvm-svn: 267239
* Introduce llvm.load.relative intrinsic.Peter Collingbourne2016-04-221-0/+25
| | | | | | | | | | | | | | | | | | | This intrinsic takes two arguments, ``%ptr`` and ``%offset``. It loads a 32-bit value from the address ``%ptr + %offset``, adds ``%ptr`` to that value and returns it. The constant folder specifically recognizes the form of this intrinsic and the constant initializers it may load from; if a loaded constant initializer is known to have the form ``i32 trunc(x - %ptr)``, the intrinsic call is folded to ``x``. LLVM provides that the calculation of such a constant initializer will not overflow at link time under the medium code model if ``x`` is an ``unnamed_addr`` function. However, it does not provide this guarantee for a constant initializer folded into a function body. This intrinsic can be used to avoid the possibility of overflows when loading from such a constant. Differential Revision: http://reviews.llvm.org/D18367 llvm-svn: 267223
* Point link to CODE_OWNERS.txt to klaus instead of viewvc.Michael Kuperstein2016-04-221-1/+1
| | | | llvm-svn: 267176
* Document source_filename in LangRef.Teresa Johnson2016-04-221-0/+20
| | | | | | | | | | | | Summary: Add documentation for new LLVM IR source_filename identifier. Reviewers: joker.eph, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18857 llvm-svn: 267150
* Add LLVMGetAttrKindID in the C API in order to facilitate migration away ↵Amaury Sechet2016-04-201-0/+3
| | | | | | | | | | | | | | | | | from LLVMAttribute Summary: LLVMAttribute has outlived its utility and is becoming a problem for C API users that what to use all the LLVM attributes. In order to help moving away from LLVMAttribute in a smooth manner, this diff introduce LLVMGetAttrKindIDInContext, which can be used instead of the enum values. See D18749 for reference. Reviewers: Wallbraker, whitequark, joker.eph, echristo, rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D19081 llvm-svn: 266842
* [libFuzzer] more trophiesKostya Serebryany2016-04-191-0/+7
| | | | llvm-svn: 266830
* [AArch64] [ARM] Make a target-independent llvm.thread.pointer intrinsic.Marcin Koscielnicki2016-04-191-0/+27
| | | | | | | | | | | | | | Both AArch64 and ARM support llvm.<arch>.thread.pointer intrinsics that just return the thread pointer. I have a pending patch that does the same for SystemZ (D19054), and there are many more targets that could benefit from one. This patch merges the ARM and AArch64 intrinsics into a single target independent one that will also be used by subsequent targets. Differential Revision: http://reviews.llvm.org/D19098 llvm-svn: 266818
* [SSP, 2/2] Create llvm.stackguard() intrinsic and lower it to LOAD_STACK_GUARDTim Shen2016-04-191-0/+35
| | | | | | | | | | | | | | | | | | | | | | | With this change, ideally IR pass can always generate llvm.stackguard call to get the stack guard; but for now there are still IR form stack guard customizations around (see getIRStackGuard()). Future SSP customization should go through LOAD_STACK_GUARD. There is a behavior change: stack guard values are not CSEed anymore, since we should never reuse the value in case that it has been spilled (and corrupted). See ssp-guard-spill.ll. This also cause the change of stack size and codegen in X86 and AArch64 test cases. Ideally we'd like to know if the guard created in llvm.stackprotector() gets spilled or not. If the value is spilled, discard the value and reload stack guard; otherwise reuse the value. This can be done by teaching register allocator to know how to rematerialize LOAD_STACK_GUARD and force a rematerialization (which seems hard), or check for spilling in expandPostRAPseudo. It only makes sense when the stack guard is a global variable, which requires more instructions to load. Anyway, this seems to go out of the scope of the current patch. llvm-svn: 266806
* Introduce a "patchable-function" function attributeSanjoy Das2016-04-191-0/+25
| | | | | | | | | | | | | | | | | Summary: The `"patchable-function"` attribute can be used by an LLVM client to influence LLVM's code generation in ways that makes the generated code easily patchable at runtime (for instance, to redirect control). Right now only one patchability scheme is supported, `"prologue-short-redirect"`, but this can be expanded in the future. Reviewers: joker.eph, rnk, echristo, dberris Subscribers: joker.eph, echristo, mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D19046 llvm-svn: 266715
* [libFuzzer] add fresh openssl trophiesKostya Serebryany2016-04-181-1/+1
| | | | llvm-svn: 266649
* IR: Use an explicit map for debug info type uniquingDuncan P. N. Exon Smith2016-04-171-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than relying on the structural equivalence of DICompositeType to merge type definitions, use an explicit map on the LLVMContext that LLParser and BitcodeReader consult when constructing new nodes. Each non-forward-declaration DICompositeType with a non-empty 'identifier:' field is stored/loaded from the type map, and the first definiton will "win". This map is opt-in: clients that expect ODR types from different modules to be merged must call LLVMContext::ensureDITypeMap. - Clients that just happen to load more than one Module in the same LLVMContext won't magically merge types. - Clients (like LTO) that want to continue to merge types based on ODR identifiers should opt-in immediately. I have updated LTOCodeGenerator.cpp, the two "linking" spots in gold-plugin.cpp, and llvm-link (unless -disable-debug-info-type-map) to set this. With this in place, it will be straightforward to remove the DITypeRef concept (i.e., referencing types by their 'identifier:' string rather than pointing at them directly). llvm-svn: 266549
* IR: Use ODR to unique DICompositeType membersDuncan P. N. Exon Smith2016-04-171-2/+11
| | | | | | | | | | | | | | Merge members that are describing the same member of the same ODR type, even if other bits differ. If the file or line differ, we don't care; if anything else differs, it's an ODR violation (and we still don't really care). For DISubprogram declarations, this looks at the LinkageName and Scope. For DW_TAG_member instances of DIDerivedType, this looks at the Name and Scope. In both cases, we know that the Scope follows ODR rules if it has a non-empty identifier. llvm-svn: 266548
* LangRef: Removed some outdated text about DIDerivedTypeDuncan P. N. Exon Smith2016-04-171-5/+2
| | | | | | | This text is also incorrect (much like r266540). It looks like I missed updating some of what I moved from SourceLevelDebugging.rst in r232566. llvm-svn: 266544
* LangRef: Fix some bugs in debug info descriptionsDuncan P. N. Exon Smith2016-04-161-4/+9
| | | | | | Fix descriptions of DICompositeType and DIDerivedType. llvm-svn: 266540
* [libFuzzer] menion the git mirror in the docsKostya Serebryany2016-04-151-0/+2
| | | | llvm-svn: 266476
* Remove every uses of getGlobalContext() in LLVM (but the C API)Mehdi Amini2016-04-147-27/+25
| | | | | | | | | | | At the same time, fixes InstructionsTest::CastInst unittest: yes you can leave the IR in an invalid state and exit when you don't destroy the context (like the global one), no longer now. This is the first part of http://reviews.llvm.org/D19094 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266379
* Revert "Support arbitrary addrspace pointers in masked load/store intrinsics"Adam Nemet2016-04-141-10/+10
| | | | | | | | This reverts commit r266086. It breaks the LTO build of gcc in SPEC2000. llvm-svn: 266282
* Update psabi link for x86-64. Add link to linux gabi supplement.James Y Knight2016-04-121-12/+2
| | | | llvm-svn: 266137
* Add __atomic_* lowering to AtomicExpandPass.James Y Knight2016-04-121-12/+162
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (Recommit of r266002, with r266011, r266016, and not accidentally including an extra unused/uninitialized element in LibcallRoutineNames) AtomicExpandPass can now lower atomic load, atomic store, atomicrmw, and cmpxchg instructions to __atomic_* library calls, when the target doesn't support atomics of a given size. This is the first step towards moving all atomic lowering from clang into llvm. When all is done, the behavior of __sync_* builtins, __atomic_* builtins, and C11 atomics will be unified. Previously LLVM would pass everything through to the ISelLowering code. There, unsupported atomic instructions would turn into __sync_* library calls. Because of that behavior, Clang currently avoids emitting llvm IR atomic instructions when this would happen, and emits __atomic_* library functions itself, in the frontend. This change makes LLVM able to emit __atomic_* libcalls, and thus will eventually allow clang to depend on LLVM to do the right thing. It is advantageous to do the new lowering to atomic libcalls in AtomicExpandPass, before ISel time, because it's important that all atomic operations for a given size either lower to __atomic_* libcalls (which may use locks), or native instructions which won't. No mixing and matching. At the moment, this code is enabled only for SPARC, as a demonstration. The next commit will expand support to all of the other targets. Differential Revision: http://reviews.llvm.org/D18200 llvm-svn: 266115
* Support arbitrary addrspace pointers in masked load/store intrinsicsArtur Pilipenko2016-04-121-10/+10
| | | | | | | | | | | | | | This is a resubmittion of 263158 change. This patch fixes the problem which occurs when loop-vectorize tries to use @llvm.masked.load/store intrinsic for a non-default addrspace pointer. It fails with "Calling a function with a bad signature!" assertion in CallInst constructor because it tries to pass a non-default addrspace pointer to the pointer argument which has default addrspace. The fix is to add pointer type as another overloaded type to @llvm.masked.load/store intrinsics. Reviewed By: reames Differential Revision: http://reviews.llvm.org/D17270 llvm-svn: 266086
* LangRef: Update example syntax for atomic load instructionMatt Arsenault2016-04-121-1/+1
| | | | llvm-svn: 266077
* This reverts commit r266002, r266011 and r266016.Rafael Espindola2016-04-121-162/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | They broke the msan bot. Original message: Add __atomic_* lowering to AtomicExpandPass. AtomicExpandPass can now lower atomic load, atomic store, atomicrmw,and cmpxchg instructions to __atomic_* library calls, when the target doesn't support atomics of a given size. This is the first step towards moving all atomic lowering from clang into llvm. When all is done, the behavior of __sync_* builtins, __atomic_* builtins, and C11 atomics will be unified. Previously LLVM would pass everything through to the ISelLowering code. There, unsupported atomic instructions would turn into __sync_* library calls. Because of that behavior, Clang currently avoids emitting llvm IR atomic instructions when this would happen, and emits __atomic_* library functions itself, in the frontend. This change makes LLVM able to emit __atomic_* libcalls, and thus will eventually allow clang to depend on LLVM to do the right thing. It is advantageous to do the new lowering to atomic libcalls in AtomicExpandPass, before ISel time, because it's important that all atomic operations for a given size either lower to __atomic_* libcalls (which may use locks), or native instructions which won't. No mixing and matching. At the moment, this code is enabled only for SPARC, as a demonstration. The next commit will expand support to all of the other targets. Differential Revision: http://reviews.llvm.org/D18200 llvm-svn: 266062
* Add the allocsize attribute to LLVM.George Burgess IV2016-04-121-0/+9
| | | | | | | | | | | | | | | | `allocsize` is a function attribute that allows users to request that LLVM treat arbitrary functions as allocation functions. This patch makes LLVM accept the `allocsize` attribute, and makes `@llvm.objectsize` recognize said attribute. The review for this was split into two patches for ease of reviewing: D18974 and D14933. As promised on the revisions, I'm landing both patches as a single commit. Differential Revision: http://reviews.llvm.org/D14933 llvm-svn: 266032
* Add __atomic_* lowering to AtomicExpandPass.James Y Knight2016-04-111-12/+162
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AtomicExpandPass can now lower atomic load, atomic store, atomicrmw, and cmpxchg instructions to __atomic_* library calls, when the target doesn't support atomics of a given size. This is the first step towards moving all atomic lowering from clang into llvm. When all is done, the behavior of __sync_* builtins, __atomic_* builtins, and C11 atomics will be unified. Previously LLVM would pass everything through to the ISelLowering code. There, unsupported atomic instructions would turn into __sync_* library calls. Because of that behavior, Clang currently avoids emitting llvm IR atomic instructions when this would happen, and emits __atomic_* library functions itself, in the frontend. This change makes LLVM able to emit __atomic_* libcalls, and thus will eventually allow clang to depend on LLVM to do the right thing. It is advantageous to do the new lowering to atomic libcalls in AtomicExpandPass, before ISel time, because it's important that all atomic operations for a given size either lower to __atomic_* libcalls (which may use locks), or native instructions which won't. No mixing and matching. At the moment, this code is enabled only for SPARC, as a demonstration. The next commit will expand support to all of the other targets. Differential Revision: http://reviews.llvm.org/D18200 llvm-svn: 266002
* [SSP] Remove llvm.stackprotectorcheck.Tim Shen2016-04-081-38/+0
| | | | | | | | | | This is a cleanup patch for SSP support in LLVM. There is no functional change. llvm.stackprotectorcheck is not needed, because SelectionDAG isn't actually lowering it in SelectBasicBlock; rather, it adds check code in FinishBasicBlock, ignoring the position where the intrinsic is inserted (See FindSplitPointForStackProtector()). llvm-svn: 265851
* [PPC] Added a note to release notesEhsan Amiri2016-04-071-1/+1
| | | | | | | A draft line added to release notes for PPC, to keep a record of changes. This is just a draft and will be rewritten towards the end of release. llvm-svn: 265694
* [GCC] Attribute ifunc support in llvmDmitry Polukhin2016-04-071-0/+19
| | | | | | | | | | | This patch add support for GCC attribute((ifunc("resolver"))) for targets that use ELF as object file format. In general ifunc is a special kind of function alias with type @gnu_indirect_function. Patch for Clang http://reviews.llvm.org/D15524 Differential Revision: http://reviews.llvm.org/D15525 llvm-svn: 265667
* NFC: make AtomicOrdering an enum classJF Bastien2016-04-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In the context of http://wg21.link/lwg2445 C++ uses the concept of 'stronger' ordering but doesn't define it properly. This should be fixed in C++17 barring a small question that's still open. The code currently plays fast and loose with the AtomicOrdering enum. Using an enum class is one step towards tightening things. I later also want to tighten related enums, such as clang's AtomicOrderingKind (which should be shared with LLVM as a 'C++ ABI' enum). This change touches a few lines of code which can be improved later, I'd like to keep it as NFC for now as it's already quite complex. I have related changes for clang. As a follow-up I'll add: bool operator<(AtomicOrdering, AtomicOrdering) = delete; bool operator>(AtomicOrdering, AtomicOrdering) = delete; bool operator<=(AtomicOrdering, AtomicOrdering) = delete; bool operator>=(AtomicOrdering, AtomicOrdering) = delete; This is separate so that clang and LLVM changes don't need to be in sync. Reviewers: jyknight, reames Subscribers: jyknight, llvm-commits Differential Revision: http://reviews.llvm.org/D18775 llvm-svn: 265602
* AMDGPU: Document address space mappingTom Stellard2016-04-061-0/+23
| | | | | | | | | | | | | | | | | Summary: Address space mapping is described in lib/Target/AMDGPU/AMDGPU.h in Doxygen comments. This patch adds the description to user guide for AMDGPU back-end. Patch By: Vedran Miletić Reviewers: tstellarAMD, arsenm Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D17046 llvm-svn: 265500
* Swift Calling Convention: swiftcc for ARM.Manman Ren2016-04-051-0/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D18769 llvm-svn: 265482
* Swift Calling Convention: add swiftcc.Manman Ren2016-04-052-0/+4
| | | | | | Differential Revision: http://reviews.llvm.org/D17863 llvm-svn: 265480
* Docs: dampen story time for atomicsJF Bastien2016-04-051-7/+3
| | | | | | Story time was nice a few years ago, but by now it's nice to state how things are, rather than explain the diff from ye olden atomic history. These were dark times. llvm-svn: 265369
* Document standard substitutions defined by lit.Paul Robinson2016-04-041-0/+29
| | | | | | | | Patch by Guilherme Bufolo! Differential Revision: http://reviews.llvm.org/D18752 llvm-svn: 265314
* Swift Calling Convention: add swifterror attribute.Manman Ren2016-04-011-0/+19
| | | | | | | | | | | | A ``swifterror`` attribute can be applied to a function parameter or an AllocaInst. This commit does not include any target-specific change. The target-specific optimization will come as a follow-up patch. Differential Revision: http://reviews.llvm.org/D18092 llvm-svn: 265189
* testcase gardening: update the emissionKind enum to the new syntax. (NFC)Adrian Prantl2016-04-012-3/+3
| | | | llvm-svn: 265081
* Change eliminateCallFramePseudoInstr() to return an iteratorHans Wennborg2016-03-311-0/+4
| | | | | | | | | | | | | | | | | | | | | This will become necessary in a subsequent change to make this method merge adjacent stack adjustments, i.e. it might erase the previous and/or next instruction. It also greatly simplifies the calls to this function from Prolog- EpilogInserter. Previously, that had a bunch of logic to resume iteration after the call; now it just continues with the returned iterator. Note that this changes the behaviour of PEI a little. Previously, it attempted to re-visit the new instruction created by eliminateCallFramePseudoInstr(). That code was added in r36625, but I can't see any reason for it: the new instructions will obviously not be pseudo instructions, they will not have FrameIndex operands, and we have already accounted for the stack adjustment. Differential Revision: http://reviews.llvm.org/D18627 llvm-svn: 265036
OpenPOWER on IntegriCloud