summaryrefslogtreecommitdiffstats
path: root/llvm/docs
Commit message (Collapse)AuthorAgeFilesLines
* [PM] Split the LoopInfo object apart from the legacy pass, creatingChandler Carruth2015-01-171-2/+2
| | | | | | | | | | a LoopInfoWrapperPass to wire the object up to the legacy pass manager. This switches all the clients of LoopInfo over and paves the way to port LoopInfo to the new pass manager. No functionality change is intended with this iteration. llvm-svn: 226373
* ProgrammersManual.rst: fix a typoHans Wennborg2015-01-171-1/+1
| | | | llvm-svn: 226367
* [PowerPC] Adjust PatchPoints for ppc64leHal Finkel2015-01-161-5/+6
| | | | | | | | | | Bill Schmidt pointed out that some adjustments would be needed to properly support powerpc64le (using the ELF V2 ABI). For one thing, R11 is not available as a scratch register, so we need to use R12. R12 is also available under ELF V1, so to maintain consistency, I flipped the order to make R12 the first scratch register in the array under both ABIs. llvm-svn: 226247
* ReleaseNotes.rst: bump version to 3.7Hans Wennborg2015-01-141-161/+8
| | | | | | The 3.6 notes are now in the 3.6 branch. llvm-svn: 226007
* Trunk is now 3.7.0svnHans Wennborg2015-01-141-2/+2
| | | | llvm-svn: 226004
* fix typosSanjay Patel2015-01-141-2/+2
| | | | llvm-svn: 225991
* SelectionDAG: add a -filter-view-dags option to llcMehdi Amini2015-01-141-1/+5
| | | | | | | | | This option takes the name of the basic block you want to visualize with -view-*-dags Differential Revision: http://reviews.llvm.org/D6948 llvm-svn: 225953
* Revert "r225811 - Revert "r225808 - [PowerPC] Add StackMap/PatchPoint support""Hal Finkel2015-01-141-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This re-applies r225808, fixed to avoid problems with SDAG dependencies along with the preceding fix to ScheduleDAGSDNodes::RegDefIter::InitNodeNumDefs. These problems caused the original regression tests to assert/segfault on many (but not all) systems. Original commit message: This commit does two things: 1. Refactors PPCFastISel to use more of the common infrastructure for call lowering (this lets us take advantage of this common code for lowering some common intrinsics, stackmap/patchpoint among them). 2. Adds support for stackmap/patchpoint lowering. For the most part, this is very similar to the support in the AArch64 target, with the obvious differences (different registers, NOP instructions, etc.). The test cases are adapted from the AArch64 test cases. One difference of note is that the patchpoint call sequence takes 24 bytes, so you can't use less than that (on AArch64 you can go down to 16). Also, as noted in the docs, we take the patchpoint address to be the actual code address (assuming the call is local in the TOC-sharing sense), which should yield higher performance than generating the full cross-DSO indirect-call sequence and is likely just as useful for JITed code (if not, we'll change it). StackMaps and Patchpoints are still marked as experimental, and so this support is doubly experimental. So go ahead and experiment! llvm-svn: 225909
* AsmParser/Bitcode: Add support for MDLocationDuncan P. N. Exon Smith2015-01-131-0/+17
| | | | | | | | | | | | This adds assembly and bitcode support for `MDLocation`. The assembly side is rather big, since this is the first `MDNode` subclass (that isn't `MDTuple`). Part of PR21433. (If you're wondering where the mountains of testcase updates are, we don't need them until I update `DILocation` and `DebugLoc` to actually use this class.) llvm-svn: 225830
* Add link to Go bindings documentation.Peter Collingbourne2015-01-131-0/+2
| | | | llvm-svn: 225815
* Revert "r225808 - [PowerPC] Add StackMap/PatchPoint support"Hal Finkel2015-01-131-6/+0
| | | | | | | Reverting this while I investiage buildbot failures (segfaulting in GetCostForDef at ScheduleDAGRRList.cpp:314). llvm-svn: 225811
* [PowerPC] Add StackMap/PatchPoint supportHal Finkel2015-01-131-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | This commit does two things: 1. Refactors PPCFastISel to use more of the common infrastructure for call lowering (this lets us take advantage of this common code for lowering some common intrinsics, stackmap/patchpoint among them). 2. Adds support for stackmap/patchpoint lowering. For the most part, this is very similar to the support in the AArch64 target, with the obvious differences (different registers, NOP instructions, etc.). The test cases are adapted from the AArch64 test cases. One difference of note is that the patchpoint call sequence takes 24 bytes, so you can't use less than that (on AArch64 you can go down to 16). Also, as noted in the docs, we take the patchpoint address to be the actual code address (assuming the call is local in the TOC-sharing sense), which should yield higher performance than generating the full cross-DSO indirect-call sequence and is likely just as useful for JITed code (if not, we'll change it). StackMaps and Patchpoints are still marked as experimental, and so this support is doubly experimental. So go ahead and experiment! llvm-svn: 225808
* Added a Mips lld milestone to the release notes for the 3.6 release.Daniel Sanders2015-01-131-4/+5
| | | | llvm-svn: 225797
* Update release notes wrt OCaml bindings.Peter Zotov2015-01-131-0/+26
| | | | llvm-svn: 225779
* Rename llvm.recoverframeallocation to llvm.framerecoverReid Kleckner2015-01-131-6/+6
| | | | | | | | This name is less descriptive, but it sort of puts things in the 'llvm.frame...' namespace, relating it to frameallocate and frameaddress. It also avoids using "allocate" and "allocation" together. llvm-svn: 225752
* Phabricator calls it "subscriber" not "cc"Paul Robinson2015-01-131-1/+2
| | | | llvm-svn: 225747
* Add the llvm.frameallocate and llvm.recoverframeallocation intrinsicsReid Kleckner2015-01-131-0/+50
| | | | | | | | | | | | | | | | | | | | | These intrinsics allow multiple functions to share a single stack allocation from one function's call frame. The function with the allocation may only perform one allocation, and it must be in the entry block. Functions accessing the allocation call llvm.recoverframeallocation with the function whose frame they are accessing and a frame pointer from an active call frame of that function. These intrinsics are very difficult to inline correctly, so the intention is that they be introduced rarely, or at least very late during EH preparation. Reviewers: echristo, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D6493 llvm-svn: 225746
* First crack at PowerPC 3.6 release notesBill Schmidt2015-01-121-1/+19
| | | | llvm-svn: 225695
* Fix silly mistake in release notes for Mips.Daniel Sanders2015-01-111-1/+1
| | | | llvm-svn: 225608
* Added release notes for the Mips target.Daniel Sanders2015-01-111-1/+68
| | | | llvm-svn: 225607
* ReleaseNotes.rst: these are for 3.6Hans Wennborg2015-01-091-1/+1
| | | | llvm-svn: 225482
* LangRef: Add usage points for distinct MDNodesDuncan P. N. Exon Smith2015-01-081-0/+4
| | | | | | Omission pointed out by Sean Silva! llvm-svn: 225479
* IR: Add 'distinct' MDNodes to bitcode and assemblyDuncan P. N. Exon Smith2015-01-081-0/+6
| | | | | | | | | | | | | | | | | | Propagate whether `MDNode`s are 'distinct' through the other types of IR (assembly and bitcode). This adds the `distinct` keyword to assembly. Currently, no one actually calls `MDNode::getDistinct()`, so these nodes only get created for: - self-references, which are never uniqued, and - nodes whose operands are replaced that hit a uniquing collision. The concept of distinct nodes is still not quite first-class, since distinct-ness doesn't yet survive across `MapMetadata()`. Part of PR22111. llvm-svn: 225474
* The Kaleidoscope tutorial should be using "mcjit" for the library,Eric Christopher2015-01-085-5/+5
| | | | | | "jit" doesn't exist anymore. llvm-svn: 225462
* [LangRef] PR22118: Hyphen is allowed in IR identifiers.Sean Silva2015-01-071-1/+1
| | | | | | | | E.g. %-foo and %fo-o. Thanks to eagle-eyed reporter Tomas Brukner. llvm-svn: 225400
* Change the .ll syntax for comdats and add a syntactic sugar.Rafael Espindola2015-01-061-6/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to make comdats always explicit in the IR, we decided to make the syntax a bit more compact for the case of a GlobalObject in a comdat with the same name. Just dropping the $name causes problems for @foo = globabl i32 0, comdat $bar = comdat ... and declare void @foo() comdat $bar = comdat ... So the syntax is changed to @g1 = globabl i32 0, comdat($c1) @g2 = globabl i32 0, comdat and declare void @foo() comdat($c1) declare void @foo() comdat llvm-svn: 225302
* [LangRef] Correct a typoHal Finkel2015-01-051-2/+2
| | | | llvm-svn: 225148
* Reformat statepoint documentation and fix a couple of typosPhilip Reames2015-01-021-87/+287
| | | | | | Patch by Ramkumar Ramachandra <artagnon@gmail.com>. llvm-svn: 225084
* Fixed 2 minor typos in the documentation.Elena Demikhovsky2014-12-291-2/+2
| | | | llvm-svn: 224917
* Documentation for Masked Load and Store intrinsics.Elena Demikhovsky2014-12-251-0/+87
| | | | llvm-svn: 224832
* IR: Make metadata typeless in assemblyDuncan P. N. Exon Smith2014-12-151-62/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that `Metadata` is typeless, reflect that in the assembly. These are the matching assembly changes for the metadata/value split in r223802. - Only use the `metadata` type when referencing metadata from a call intrinsic -- i.e., only when it's used as a `Value`. - Stop pretending that `ValueAsMetadata` is wrapped in an `MDNode` when referencing it from call intrinsics. So, assembly like this: define @foo(i32 %v) { call void @llvm.foo(metadata !{i32 %v}, metadata !0) call void @llvm.foo(metadata !{i32 7}, metadata !0) call void @llvm.foo(metadata !1, metadata !0) call void @llvm.foo(metadata !3, metadata !0) call void @llvm.foo(metadata !{metadata !3}, metadata !0) ret void, !bar !2 } !0 = metadata !{metadata !2} !1 = metadata !{i32* @global} !2 = metadata !{metadata !3} !3 = metadata !{} turns into this: define @foo(i32 %v) { call void @llvm.foo(metadata i32 %v, metadata !0) call void @llvm.foo(metadata i32 7, metadata !0) call void @llvm.foo(metadata i32* @global, metadata !0) call void @llvm.foo(metadata !3, metadata !0) call void @llvm.foo(metadata !{!3}, metadata !0) ret void, !bar !2 } !0 = !{!2} !1 = !{i32* @global} !2 = !{!3} !3 = !{} I wrote an upgrade script that handled almost all of the tests in llvm and many of the tests in cfe (even handling many `CHECK` lines). I've attached it (or will attach it in a moment if you're speedy) to PR21532 to help everyone update their out-of-tree testcases. This is part of PR21532. llvm-svn: 224257
* Require python 2.7.Rafael Espindola2014-12-123-4/+4
| | | | | | | | | | | | | We were already requiring 2.5, which meant that people on old linux distros had to upgrade anyway. Requiring python 2.6 will make supporting 3.X easier as we can use the 3.X exception syntax. According to the discussion on llvmdev, there is not much value is requiring just 2.6, we may as well just require 2.7. llvm-svn: 224129
* Added documentation for MergeFunctions pass:Stepan Dyatkovskiy2014-12-103-9/+822
| | | | | | Pass looks for equivalent functions that are mergable and folds them. llvm-svn: 223931
* Add argument variable support to the debug info tutorialEric Christopher2014-12-091-9/+43
| | | | | | | and rearrange the prologue source location hack to immediately after it. llvm-svn: 223725
* Clean up the rst for the debug info tutorialEric Christopher2014-12-081-52/+52
| | | | llvm-svn: 223682
* InstrProf: An intrinsic and lowering for instrumentation based profilingJustin Bogner2014-12-081-0/+44
| | | | | | | | | | | | | | | | | | | | | Introduce the ``llvm.instrprof_increment`` intrinsic and the ``-instrprof`` pass. These provide the infrastructure for writing counters for profiling, as in clang's ``-fprofile-instr-generate``. The implementation of the instrprof pass is ported directly out of the CodeGenPGO classes in clang, and with the followup in clang that rips that code out to use these new intrinsics this ends up being NFC. Doing the instrumentation this way opens some doors in terms of improving the counter performance. For example, this will make it simple to experiment with alternate lowering strategies, and allows us to try handling profiling specially in some optimizations if we want to. Finally, this drastically simplifies the frontend and puts all of the lowering logic in one place. llvm-svn: 223672
* Add Chapter 8 to the Kaleidoscope tutorial. This chapter addsEric Christopher2014-12-082-262/+687
| | | | | | | | | a description of how to add debug information using DWARF and DIBuilder to the language. Thanks to David Blaikie for his assistance with this tutorial. llvm-svn: 223671
* Add a section to Statepoint docs mentioning shared bugzilla search and ↵Philip Reames2014-12-041-0/+4
| | | | | | standard mailing lists llvm-svn: 223374
* Minor typo and link fixes for Statepoint documentationPhilip Reames2014-12-041-5/+3
| | | | llvm-svn: 223327
* Fix grammar-o.Nico Weber2014-12-031-1/+1
| | | | llvm-svn: 223265
* Fix sphinx error from Statepoints.rstMatt Arsenault2014-12-031-0/+5
| | | | | | It was complaining it wasn't included in any toctree llvm-svn: 223254
* Fix a typo in the documentation of LTOBenjamin Poulain2014-12-031-1/+1
| | | | | | | | Fix defininitions->definitions. Reviewed by David Blaikie. llvm-svn: 223216
* Prologue supportPeter Collingbourne2014-12-033-28/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch by Ben Gamari! This redefines the `prefix` attribute introduced previously and introduces a `prologue` attribute. There are a two primary usecases that these attributes aim to serve, 1. Function prologue sigils 2. Function hot-patching: Enable the user to insert `nop` operations at the beginning of the function which can later be safely replaced with a call to some instrumentation facility 3. Runtime metadata: Allow a compiler to insert data for use by the runtime during execution. GHC is one example of a compiler that needs this functionality for its tables-next-to-code functionality. Previously `prefix` served cases (1) and (2) quite well by allowing the user to introduce arbitrary data at the entrypoint but before the function body. Case (3), however, was poorly handled by this approach as it required that prefix data was valid executable code. Here we redefine the notion of prefix data to instead be data which occurs immediately before the function entrypoint (i.e. the symbol address). Since prefix data now occurs before the function entrypoint, there is no need for the data to be valid code. The previous notion of prefix data now goes under the name "prologue data" to emphasize its duality with the function epilogue. The intention here is to handle cases (1) and (2) with prologue data and case (3) with prefix data. References ---------- This idea arose out of discussions[1] with Reid Kleckner in response to a proposal to introduce the notion of symbol offsets to enable handling of case (3). [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073235.html Test Plan: testsuite Differential Revision: http://reviews.llvm.org/D6454 llvm-svn: 223189
* [Statepoints 4/4] Statepoint infrastructure for garbage collection: ↵Philip Reames2014-12-021-0/+209
| | | | | | | | | | | | | Documentation This is the fourth and final patch in the statepoint series. It contains the documentation for the statepoint intrinsics and their usage. There's definitely still room to improve the documentation here, but I wanted to get this landed so it was available for others. There will likely be a series of small cleanup changes over the next few weeks as we work to clarify and revise the documentation. If you have comments or questions, please feel free to discuss them either in this commit thread, the original review thread, or on llvmdev. Comments are more than welcome. Reviewed by: atrick, ributzka Differential Revision: http://reviews.llvm.org/D5683 llvm-svn: 223143
* [OCaml] Move Llvm.clone_module to its own Llvm_transform_utils module.Peter Zotov2014-12-011-0/+1
| | | | | | | This way most code won't link this (substantially large) library, if compiled statically with LLVM. llvm-svn: 223072
* [OCaml] [cmake] Add CMake buildsystem for OCaml.Peter Zotov2014-12-011-0/+42
| | | | | | Closes PR15325. llvm-svn: 223071
* Remove neverHasSideEffects support from TableGen CodeGenInstruction. ↵Craig Topper2014-11-261-1/+0
| | | | | | Everyone should use hasSideEffects now. llvm-svn: 222809
* Clarify wording in the LangRef around !invariant.loadPhilip Reames2014-11-241-4/+5
| | | | | | | | | | | | | | | Clarify the wording around !invariant.load to properly reflect the semantics of such loads with respect to control dependence and location lifetime. To the best of my knowledge, the revised wording respects the actual implementation and understanding of issues involved highlighted in the recent 'Optimization hints for "constant" loads' thread on LLVMDev. In particular, I'm aiming for the following results: - To clarify that an invariant.load can fault and must respect control dependence. In particular, it is not sound to unconditionally pull an invariant load out of a loop if that loop would potentially never execute. - To clarify that the invariant nature of a given pointer does not preclude the modification of that location through a pointer which is unrelated to the load operand. In particular, initializing a location and then passing a pointer through an opaque intrinsic which produces a new unrelated pointer, should behave as expected provided that the intrinsic is memory dependent on the initializing store. - To clarify that storing a value to an invariant location is defined. It can not, for example, be considered unreachable. The value stored can be assumed to be equal to the value of any previous (or following!) invariant load, but the store itself is defined. I recommend that anyone interested in using !invariant.load, or optimizing for them, read over the discussion in the review thread. A number of motivating examples are discussed. Differential Revision: http://reviews.llvm.org/D6346 llvm-svn: 222700
* Correct path to regression tests in ExtendingLLVMSergey Dmitrouk2014-11-241-4/+4
| | | | llvm-svn: 222678
* Clarify the description of the noalias attributeHal Finkel2014-11-211-13/+16
| | | | | | | | | | | | | | | | | | | | | | The previous description of the noalias attribute did not accurately specify the implemented semantics, and the terminology used differed unnecessarily from that used by the C specification to define the semantics of restrict. For the argument attribute, the semantics can be precisely specified in terms of objects accessed through pointers based on the arguments, and this is now what is done. Saying that the semantics are 'slightly weaker' than that provided by C99 restrict is not really useful without further elaboration, so that has been removed from the sentence. noalias on a return value is really used to mean that the function is malloc-like (and, in fact, we use this attribute to represent __attribute__((malloc)) in Clang), and this is a stronger guarantee than that provided by restrict (because it is a property of the pointed-to memory region, not just a guarantee on object access). Clarifying this is relevant to fixing (and was motivated by the discussion on) PR21556. llvm-svn: 222497
OpenPOWER on IntegriCloud