summaryrefslogtreecommitdiffstats
path: root/llvm/docs
Commit message (Collapse)AuthorAgeFilesLines
* [Kaleidoscope] Add an initial "Building an ORC JIT" tutorial chapter.Lang Hames2016-05-232-0/+291
| | | | | | | | | This is a work in progress - the chapter text is incomplete, though the example code compiles and runs. Feedback and patches are, as usual, most welcome. llvm-svn: 270487
* Extract renaming from D19181Amaury Sechet2016-05-231-1/+1
| | | | | | | | | | | | Summary: This needs to get in before anything is released concerning attribute. If the old name gets in the wild, then we are stuck with it forever. Putting it in its own diff should getting that part at least in fast. Reviewers: Wallbraker, whitequark, joker.eph, echristo, rafael, jyknight Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D20417 llvm-svn: 270452
* docs: Update and clean up BitCodeFormat.rst.Peter Collingbourne2016-05-171-1/+14
| | | | llvm-svn: 269857
* Fail early on unknown appending linkage variables.Rafael Espindola2016-05-161-0/+5
| | | | | | | | | | | | | In practice only a few well known appending linkage variables work. Currently if codegen sees an unknown appending linkage variable it will just print it as a regular global. That is wrong as the symbol in the produced object file has different semantics as the one provided by the appending linkage. This just errors early instead of producing a broken .o. llvm-svn: 269706
* [Docs] Add some requirements to the Testing GuideRenato Golin2016-05-141-0/+6
| | | | | | Patch by Diana Picus. llvm-svn: 269566
* [Docs] clarify semantics of x.with.overflow intrinsicsJohn Regehr2016-05-121-1/+20
| | | | | | Differential Revision: http://reviews.llvm.org/D20151 llvm-svn: 269346
* All llvm.deoptimize declarations must use the same calling conventionSanjoy Das2016-05-121-0/+3
| | | | | | | | | | | | | | | | | This new verifier rule lets us unambigously pick a calling convention when creating a new declaration for `@llvm.experimental.deoptimize.<ty>`. It is also congruent with our lowering strategy -- since all calls to `@llvm.experimental.deoptimize` are lowered to calls to `__llvm_deoptimize`, it is reasonable to enforce a unique calling convention. Some of the tests that were breaking this verifier rule have had to be split up into different .ll files. The inliner was violating this rule as well, and has been fixed to avoid producing invalid IR. llvm-svn: 269261
* Most common problem is that I get md5 hashes, not crypt hashes.Chris Lattner2016-05-111-2/+4
| | | | llvm-svn: 269157
* [libFuzzer] mention the AFL driver in the docsKostya Serebryany2016-05-101-1/+4
| | | | llvm-svn: 269143
* Make "@name =" mandatory for globals in .ll files.Rafael Espindola2016-05-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | An oddity of the .ll syntax is that the "@var = " in @var = global i32 42 is optional. Writing just global i32 42 is equivalent to @0 = global i32 42 This means that there is a pretty big First set at the top level. The current implementation maintains it manually. I was trying to refactor it, but then started wondering why keep it a all. I personally find the above syntax confusing. It looks like something is missing. This patch removes the feature and simplifies the parser. llvm-svn: 269096
* [docs] Fix unexpected indentation in HowToCrossCompileLLVM.rstRenato Golin2016-05-101-0/+3
| | | | | | | Seems like my sphynx version is different than the one in the bot, as it accepted everything locally. I think this is the right fix... llvm-svn: 269062
* [docs] Change CrossCompilation guidde to reflect changes in Clang/GCCRenato Golin2016-05-101-11/+38
| | | | | | | | | | | | | HowToCrossCompile was outdated and generating too much traffic on the mailing list with similar queries. This change helps offset most of the problems that were reported recently including: * Removing the -ccc-gcc-name, adding --sysroot * Making references to Debian's multiarch for target libraries * Expanding -DCMAKE_CXX_FLAGS for both GCC and Clang * Some formatting and clarifications in the text llvm-svn: 269054
* [libFuzzer] add a test for libFuzzer+ubsan, extend the docs on using ↵Kostya Serebryany2016-05-091-5/+8
| | | | | | libFuzzer+ubsan llvm-svn: 268968
* [libFuzzer] reshuffle docs moreKostya Serebryany2016-05-091-1/+1
| | | | llvm-svn: 268961
* [libFuzzer] reshuffle docs Kostya Serebryany2016-05-091-35/+37
| | | | llvm-svn: 268959
* [libFuzzer] better document the -merge=1 flag, part 2 Kostya Serebryany2016-05-091-0/+7
| | | | llvm-svn: 268958
* [libFuzzer] better document the -merge=1 flagKostya Serebryany2016-05-091-4/+12
| | | | llvm-svn: 268957
* [libFuzzer] modify the docs for startup/initKostya Serebryany2016-05-061-3/+7
| | | | llvm-svn: 268824
* [libFuzzer] tweak the documentation about rss_limitKostya Serebryany2016-05-061-3/+1
| | | | llvm-svn: 268822
* [libFuzzer] enhance -rss_limit_mb and enable by default. Now it will print ↵Kostya Serebryany2016-05-061-0/+6
| | | | | | the OOM reproducer. llvm-svn: 268821
* [libFuzzer] more trophiesKostya Serebryany2016-05-061-0/+2
| | | | llvm-svn: 268788
* SDAG: Rename Select->SelectImpl and repurpose Select as returning voidJustin Bogner2016-05-051-0/+4
| | | | | | | | | | | | | | This is a step towards removing the rampant undefined behaviour in SelectionDAG, which is a part of llvm.org/PR26808. We rename SelectionDAGISel::Select to SelectImpl and update targets to match, and then change Select to return void and consolidate the sketchy behaviour we're trying to get away from there. Next, we'll update backends to implement `void Select(...)` instead of SelectImpl and eventually drop the base Select implementation. llvm-svn: 268693
* [libFuzzer] better docs for coverageKostya Serebryany2016-05-051-5/+8
| | | | llvm-svn: 268656
* Remove bit-rotten CppBackend.James Y Knight2016-05-052-10/+8
| | | | | | | | | | | | | | | | | This backend was supposed to generate C++ code which will re-construct the LLVM IR passed as input. This seems to me to have very marginal usefulness in the first place. However, the code has never been updated to use IRBuilder, which makes its current value negative -- people who look at the output may be steered to use the *wrong* C++ APIs to construct IR. Furthermore, it's generated code that doesn't compile since at least 2013. Differential Revision: http://reviews.llvm.org/D19942 llvm-svn: 268631
* [NVPTX:doc] Update code examples to conform to the latest IR.Jingyue Wu2016-05-041-23/+23
| | | | llvm-svn: 268522
* Add an address space for the X86 SS segment.David L Kreitzer2016-05-031-3/+3
| | | | | | | | Patch by Michael LeMay (michael.lemay@intel.com) Differential Revision: http://reviews.llvm.org/D17093 llvm-svn: 268431
* 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
OpenPOWER on IntegriCloud