summaryrefslogtreecommitdiffstats
path: root/llvm/docs
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix Sphinx error about duplicate label in CommandLine.rst:1560 and ↵Hans Wennborg2015-07-141-1/+1
| | | | | | CoverageMappingFormat.rst llvm-svn: 242245
* ReleaseNotes.rst: Bump version to 3.8Hans Wennborg2015-07-141-17/+5
| | | | | | The notes for 3.7 are on the 3.7 branch. llvm-svn: 242237
* Update the trunk version to 3.8.0svn.Hans Wennborg2015-07-141-2/+2
| | | | llvm-svn: 242222
* [PowerPC] Use the ABI indirect-call protocol for patchpointsHal Finkel2015-07-141-6/+4
| | | | | | | | | | | | We used to take the address specified as the direct target of the patchpoint and did no TOC-pointer handling. This, however, as not all that useful, because MCJIT tends to create a lot of modules, and they have their own TOC sections. Thus, to call from the generated code to other generated code, you really need to switch TOC pointers. Make this work as expected, and under ELFv1, tread the address as the function descriptor address so that the correct TOC pointer can be loaded. llvm-svn: 242217
* [mips] Explained the 'w' modifier in the Inline Assembler documentation.Daniel Sanders2015-07-131-2/+5
| | | | | | | | It exists for compatibility with GCC which requires it to print MSA registers for the 'f' constraint. Although LLVM doesn't need it, the 'w' modifier should still be used for portability between the two compilers. llvm-svn: 242015
* Fix PR24099 reported by Tomas Brukner.Yaron Keren2015-07-121-1/+1
| | | | llvm-svn: 241997
* Add argmemonly attribute.Igor Laevsky2015-07-111-0/+8
| | | | | | | | This change adds new attribute called "argmemonly". Function marked with this attribute can only access memory through it's argument pointers. This attribute directly corresponds to the "OnlyAccessesArgumentPointees" ModRef behaviour in alias analysis. Differential Revision: http://reviews.llvm.org/D10398 llvm-svn: 241979
* Define a new intrinsic @llvm.canonicalize.Owen Anderson2015-07-111-0/+69
| | | | | | | | This is used the canonicalize floating point values, which is useful for implementing certain numeric primitives. See the LangRef changes for the full details of its semantics. llvm-svn: 241977
* Add support for fast-math flags to the FCmp instruction.James Molloy2015-07-101-3/+12
| | | | | | | | | | | | | | FCmp behaves a lot like a floating-point binary operator in many ways, and can benefit from fast-math information. Flags such as nsz and nnan can affect if this fcmp (in combination with a select) can be treated as a fminnum/fmaxnum operation. This adds backwards-compatible bitcode support, IR parsing and writing, LangRef changes and IRBuilder changes. I'll need to audit InstSimplify and InstCombine in a followup to find places where flags should be copied. llvm-svn: 241901
* Revert the new EH instructionsDavid Majnemer2015-07-101-355/+1
| | | | | | This reverts commits r241888-r241891, I didn't mean to commit them. llvm-svn: 241893
* Address Joseph's review comments.David Majnemer2015-07-101-8/+12
| | | | llvm-svn: 241890
* Address Reid's review feedback.David Majnemer2015-07-101-12/+13
| | | | llvm-svn: 241889
* New EH representation for MSVC compatibilityDavid Majnemer2015-07-101-1/+350
| | | | | | | | | | | | | | | Summary: This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Reviewers: rnk, JosephTremoulet, reames, nlewycky, rjmccall Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11041 llvm-svn: 241888
* Extended syntax of vector version of getelementptr instruction.Elena Demikhovsky2015-07-091-4/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | The justification of this change is here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-March/082989.html According to the current GEP syntax, vector GEP requires that each index must be a vector with the same number of elements. %A = getelementptr i8, <4 x i8*> %ptrs, <4 x i64> %offsets In this implementation I let each index be or vector or scalar. All vector indices must have the same number of elements. The scalar value will mean the splat vector value. (1) %A = getelementptr i8, i8* %ptr, <4 x i64> %offsets or (2) %A = getelementptr i8, <4 x i8*> %ptrs, i64 %offset In all cases the %A type is <4 x i8*> In the case (2) we add the same offset to all pointers. The case (1) covers C[B[i]] case, when we have the same base C and different offsets B[i]. The documentation is updated. http://reviews.llvm.org/D10496 llvm-svn: 241788
* Expand LangRef.html's documentation on LLVM's inline assembly.James Y Knight2015-07-081-9/+619
| | | | | | | | | | While trying to figure out how this was all supposed to work, I figured I'd start writing down some documentation, since it was basically completely missing. Differential Revision: http://reviews.llvm.org/D10816 llvm-svn: 241698
* [WinEH] Add localaddress intrinsic instead of using frameaddressReid Kleckner2015-07-071-4/+4
| | | | | | | Clang uses this for SEH finally. The new intrinsic will produce the right value when stack realignment is required. llvm-svn: 241643
* Rename llvm.frameescape and llvm.framerecover to localescape and localrecoverReid Kleckner2015-07-072-27/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Initially, these intrinsics seemed like part of a family of "frame" related intrinsics, but now I think that's more confusing than helpful. Initially, the LangRef specified that this would create a new kind of allocation that would be allocated at a fixed offset from the frame pointer (EBP/RBP). We ended up dropping that design, and leaving the stack frame layout alone. These intrinsics are really about sharing local stack allocations, not frame pointers. I intend to go further and add an `llvm.localaddress()` intrinsic that returns whatever register (EBP, ESI, ESP, RBX) is being used to address locals, which should not be confused with the frame pointer. Naming suggestions at this point are welcome, I'm happy to re-run sed. Reviewers: majnemer, nicholas Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11011 llvm-svn: 241633
* [NFC] Minor editorial fixes to the CodeGen docs.Charlie Turner2015-07-021-2/+2
| | | | llvm-svn: 241249
* Expand Phabricator docs slightlyScott Douglass2015-07-011-7/+9
| | | | llvm-svn: 241161
* Getting started docs: https, and check signatureJF Bastien2015-07-011-1/+5
| | | | | | | | | | | | | | Summary: Download should be over https, not insecure ftp at least for the signature and key files. The signature should also get verified. Test Plan: None Reviewers: chandlerc Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10845 llvm-svn: 241138
* Fix several typos in LangRef.rst related to loop unrolling metadata.Mark Heffernan2015-06-301-4/+4
| | | | llvm-svn: 241126
* [FaultMaps] Let the frontend pre-select implicit null check candidates.Sanjoy Das2015-06-301-1/+32
| | | | | | | | | | | | | | | | | | Summary: This change introduces a !make.implicit metadata that allows the frontend to pre-select the set of explicit null checks that will be considered for transformation into implicit null checks. The reason for not using profiling data instead of !make.implicit is explained in the change to `FaultMaps.rst`. Reviewers: atrick, reames, pgavlin, JosephTremoulet Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10824 llvm-svn: 241116
* COFF: Do not assign linker-weak symbols to selectany comdat sections.Peter Collingbourne2015-06-301-3/+5
| | | | | | | | | | | | | | It is mandatory to specify a comdat in order to receive comdat semantics for a symbol. We were previously getting this wrong in -function-sections mode; linker-weak symbols were being emitted in a selectany comdat. This change causes such symbols to use a noduplicates comdat instead, fixing the inconsistency. Also correct an inaccuracy in the docs. Differential Revision: http://reviews.llvm.org/D10828 llvm-svn: 241103
* [FaultMaps][Docs] Document the ImplicitNullChecks pass.Sanjoy Das2015-06-291-0/+42
| | | | llvm-svn: 241009
* AMDGPU/SI: Update amd_kernel_code_t definition and add assembler supportTom Stellard2015-06-261-0/+57
| | | | | | | | | | Reviewers: arsenm Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10772 llvm-svn: 240839
* AMDGPU/SI: Add hsa code object directivesTom Stellard2015-06-261-0/+26
| | | | | | | | | | Reviewers: arsenm Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10757 llvm-svn: 240831
* Make llvm-dwarfdump exit with non-zero exit code if error was occured.Alexey Samsonov2015-06-251-2/+2
| | | | llvm-svn: 240729
* docs: Update allowed values for LLVM_USE_SANITIZERJustin Bogner2015-06-221-2/+2
| | | | | | | "Thread" and combinations of "Address" and "Undefined" have been accepted for a while now. llvm-svn: 240316
* [NFC] Capitalization in documentation.Sanjoy Das2015-06-221-1/+1
| | | | llvm-svn: 240303
* [PM/AA] Hoist the AliasResult enum out of the AliasAnalysis class.Chandler Carruth2015-06-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | This will allow classes to implement the AA interface without deriving from the class or referencing an internal enum of some other class as their return types. Also, to a pretty fundamental extent, concepts such as 'NoAlias', 'MayAlias', and 'MustAlias' are first class concepts in LLVM and we aren't saving anything by scoping them heavily. My mild preference would have been to use a scoped enum, but that feature is essentially completely broken AFAICT. I'm extremely disappointed. For example, we cannot through any reasonable[1] means construct an enum class (or analog) which has scoped names but converts to a boolean in order to test for the possibility of aliasing. [1]: Richard Smith came up with a "solution", but it requires class templates, and lots of boilerplate setting up the enumeration multiple times. Something like Boost.PP could potentially bundle this up, but even that would be quite painful and it doesn't seem realistically worth it. The enum class solution would probably work without the need for a bool conversion. Differential Revision: http://reviews.llvm.org/D10495 llvm-svn: 240255
* Fix "the the" in comments.Eric Christopher2015-06-192-2/+2
| | | | llvm-svn: 240112
* [docs] Fix "WARNING: Title underline too short."David Majnemer2015-06-171-1/+1
| | | | llvm-svn: 239947
* Move the personality function from LandingPadInst to FunctionDavid Majnemer2015-06-172-15/+24
| | | | | | | | | | | | | | | | | | | The personality routine currently lives in the LandingPadInst. This isn't desirable because: - All LandingPadInsts in the same function must have the same personality routine. This means that each LandingPadInst beyond the first has an operand which produces no additional information. - There is ongoing work to introduce EH IR constructs other than LandingPadInst. Moving the personality routine off of any one particular Instruction and onto the parent function seems a lot better than have N different places a personality function can sneak onto an exceptional function. Differential Revision: http://reviews.llvm.org/D10429 llvm-svn: 239940
* Protection against stack-based memory corruption errors using SafeStackPeter Collingbourne2015-06-151-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the safe stack instrumentation pass to LLVM, which separates the program stack into a safe stack, which stores return addresses, register spills, and local variables that are statically verified to be accessed in a safe way, and the unsafe stack, which stores everything else. Such separation makes it much harder for an attacker to corrupt objects on the safe stack, including function pointers stored in spilled registers and return addresses. You can find more information about the safe stack, as well as other parts of or control-flow hijack protection technique in our OSDI paper on code-pointer integrity (http://dslab.epfl.ch/pubs/cpi.pdf) and our project website (http://levee.epfl.ch). The overhead of our implementation of the safe stack is very close to zero (0.01% on the Phoronix benchmarks). This is lower than the overhead of stack cookies, which are supported by LLVM and are commonly used today, yet the security guarantees of the safe stack are strictly stronger than stack cookies. In some cases, the safe stack improves performance due to better cache locality. Our current implementation of the safe stack is stable and robust, we used it to recompile multiple projects on Linux including Chromium, and we also recompiled the entire FreeBSD user-space system and more than 100 packages. We ran unit tests on the FreeBSD system and many of the packages and observed no errors caused by the safe stack. The safe stack is also fully binary compatible with non-instrumented code and can be applied to parts of a program selectively. This patch is our implementation of the safe stack on top of LLVM. The patches make the following changes: - Add the safestack function attribute, similar to the ssp, sspstrong and sspreq attributes. - Add the SafeStack instrumentation pass that applies the safe stack to all functions that have the safestack attribute. This pass moves all unsafe local variables to the unsafe stack with a separate stack pointer, whereas all safe variables remain on the regular stack that is managed by LLVM as usual. - Invoke the pass as the last stage before code generation (at the same time the existing cookie-based stack protector pass is invoked). - Add unit tests for the safe stack. Original patch by Volodymyr Kuznetsov and others at the Dependable Systems Lab at EPFL; updates and upstreaming by myself. Differential Revision: http://reviews.llvm.org/D6094 llvm-svn: 239761
* Unbreak docs build from r239740.Sanjoy Das2015-06-151-0/+4
| | | | | | Add FaultMaps.rst to toctree. llvm-svn: 239747
* Unbreak the build from r239740.Sanjoy Das2015-06-151-1/+1
| | | | | | Do not re-use an enum name as a field name. Some bots don't like this. llvm-svn: 239746
* [CodeGen] Introduce a FAULTING_LOAD_OP pseudo-op.Sanjoy Das2015-06-151-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This instruction encodes a loading operation that may fault, and a label to branch to if the load page-faults. The locations of potentially faulting loads and their "handler" destinations are recorded in a FaultMap section, meant to be consumed by LLVM's clients. Nothing generates FAULTING_LOAD_OP instructions yet, but they will be used in a future change. The documentation (FaultMaps.rst) needs improvement and I will update this diff with a more expanded version shortly. Depends on D10196 Reviewers: rnk, reames, AndyAyers, ab, atrick, pgavlin Reviewed By: atrick, pgavlin Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10197 llvm-svn: 239740
* R600 -> AMDGPU renameTom Stellard2015-06-134-11/+11
| | | | llvm-svn: 239657
* R600/SI: Add assembler support for FLAT instructionsTom Stellard2015-06-121-0/+5
| | | | | | | | - Add glc, slc, and tfe operands to flat instructions - Add missing flat instructions - Fix the encoding of flat_load_dwordx3 and flat_store_dwordx3. llvm-svn: 239637
* [TableGen] Correct the documentation for 'foreach' in the Language Intro.Craig Topper2015-06-061-1/+1
| | | | llvm-svn: 239204
* [docs] Document "LGTM" in the lexicon.Sean Silva2015-06-041-0/+4
| | | | llvm-svn: 239085
* [IR/AsmWriter] Output escape sequences if the first character isdigit()Filipe Cabecinhas2015-06-021-0/+5
| | | | | | | | | | | | | | | If the first character in a metadata attachment's name is a digit, it has to be output using an escape sequence, otherwise it's not valid text IR. Removed an over-zealous assert from LLVMContext which didn't allow this. The rule should only apply to text IR. Actual names can have any sequence of non-NUL bytes. Also added some documentation on accepted names. Bug found with AFL fuzz. llvm-svn: 238867
* [docs] fix the declarations of the llvm.nvvm.ptr.gen.to.* intrinsicsJingyue Wu2015-05-291-4/+4
| | | | | | | | | | | | | | | | | | Summary: These intrinsics should take a generic input address space and outputs a non-generic address space. Test Plan: no Reviewers: jholewinski, eliben Reviewed By: eliben Subscribers: eliben, jholewinski, llvm-commits Differential Revision: http://reviews.llvm.org/D10132 llvm-svn: 238620
* [YAMLIO] Make line-wrapping configurable and test it.Frederic Riss2015-05-291-3/+11
| | | | | | | | | | | | | | | | Summary: We would wrap flow mappings and sequences when they go over a hardcoded 70 characters limit. Make the wrapping column configurable (and default to 70 co the change should be NFC for current users). Passing 0 allows to completely suppress the wrapping which makes it easier to handle in tools like FileCheck. Reviewers: bogner Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10109 llvm-svn: 238584
* Update documentation for llvm-profdata.Diego Novillo2015-05-281-0/+30
| | | | | | | These options have been present for a while, but I had never updated the documentation. Fixed. llvm-svn: 238511
* Add some more detailed docs about the current state of Phabricator andChandler Carruth2015-05-271-1/+11
| | | | | | reviwes.llvm.org to help reduce confusion. llvm-svn: 238295
* Add initial support for the convergent attribute.Owen Anderson2015-05-261-0/+7
| | | | llvm-svn: 238264
* [lib/Fuzzer] make the fuzzing timeout 1200 seconds by default (was: infinity)Kostya Serebryany2015-05-261-1/+1
| | | | llvm-svn: 238251
* [lib/Fuzzer] fix docsKostya Serebryany2015-05-261-3/+3
| | | | llvm-svn: 238236
* [lib/Fuzzer] mention the user-supplied mutatorsKostya Serebryany2015-05-221-0/+8
| | | | llvm-svn: 238062
OpenPOWER on IntegriCloud