summaryrefslogtreecommitdiffstats
path: root/llvm/docs
Commit message (Collapse)AuthorAgeFilesLines
...
* [LangRef] add note about format of FP typesSanjay Patel2018-03-211-0/+4
| | | | llvm-svn: 328105
* [LangRef] more hyphens: always write "floating-point"Sanjay Patel2018-03-211-192/+192
| | | | | | | | | We were inconsistent, sometimes even within a single sentence. The consensus seems clear that the FP we're looking for is spelled "floating-point". Without the hyphen, it's a "surprisingly fine" jazz album. llvm-svn: 328098
* [TableGen] Pass result of std::unique to vector::erase instead of ↵Craig Topper2018-03-205-1/+98
| | | | | | calculating a size and calling resize. llvm-svn: 328031
* [LangRef] fix link formattingSanjay Patel2018-03-201-11/+11
| | | | llvm-svn: 328001
* [LangRef] describe the default FP environmentSanjay Patel2018-03-201-15/+38
| | | | | | | | | | Follow-up for D44216: add a section and examples to describe the FP env. Also, add pointers from the FP instructions to this new section to reduce bloat. Differential Revision: https://reviews.llvm.org/D44318 llvm-svn: 327998
* [Kaleidoscope] doc fixSjoerd Meijer2018-03-201-5/+5
| | | | | | | | This fixes the compile command of the example in Chapter 2. Differential Revision: https://reviews.llvm.org/D43196 llvm-svn: 327989
* [Release Notes] Add release note for llvm-mca.Andrea Di Biagio2018-03-201-0/+5
| | | | | | Differential Revision: https://reviews.llvm.org/D44636 llvm-svn: 327965
* TableGen: Remove the cast-from-string-to-variable-reference featureNicolai Haehnle2018-03-191-4/+0
| | | | | | | | | | | | | | | | | | | Summary: Cast-from-string for records isn't going away, but cast-from-string for variables is a pretty dodgy feature to have, especially when referencing template arguments. It's doubtful that this ever worked in a reliable way, and nobody seems to be using it, so let's get rid of it and get some related cleanups. Change-Id: I395ac8a43fef4cf98e611f2f552300d21e99b66a Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44195 llvm-svn: 327844
* [dsymutil] Rename llvm-dsymutil -> dsymutilJonas Devlieghere2018-03-181-8/+8
| | | | | | | | | | | Now that almost all functionality of Apple's dsymutil has been upstreamed, the open source variant can be used as a drop in replacement. Hence we feel it's no longer necessary to have the llvm prefix. Differential revision: https://reviews.llvm.org/D44527 llvm-svn: 327790
* [X86] Added support for nocf_check attribute for indirect Branch TrackingOren Ben Simhon2018-03-172-0/+7
| | | | | | | | | | | | | | | X86 Supports Indirect Branch Tracking (IBT) as part of Control-Flow Enforcement Technology (CET). IBT instruments ENDBR instructions used to specify valid targets of indirect call / jmp. The `nocf_check` attribute has two roles in the context of X86 IBT technology: 1. Appertains to a function - do not add ENDBR instruction at the beginning of the function. 2. Appertains to a function pointer - do not track the target function of this pointer by adding nocf_check prefix to the indirect-call instruction. This patch implements `nocf_check` context for Indirect Branch Tracking. It also auto generates `nocf_check` prefixes before indirect branchs to jump tables that are guarded by range checks. Differential Revision: https://reviews.llvm.org/D41879 llvm-svn: 327767
* [IR] Avoid the need to prefix MS C++ symbols with '\01'Reid Kleckner2018-03-162-5/+13
| | | | | | | | | | | | | | | | | | | | Now the Windows mangling modes ('w' and 'x') do not do any mangling for symbols starting with '?'. This means that clang can stop adding the hideous '\01' leading escape. This means LLVM debug logs are less likely to contain ASCII escape characters and it will be easier to copy and paste MS symbol names from IR. Finally. For non-Windows platforms, names starting with '?' still get IR mangling, so once clang stops escaping MS C++ names, we will get extra '_' prefixing on MachO. That's fine, since it is currently impossible to construct a triple that uses the MS C++ ABI in clang and emits macho object files. Differential Revision: https://reviews.llvm.org/D7775 llvm-svn: 327734
* TableGen: Add !ne, !le, !lt, !ge, and !gt comparisonsNicolai Haehnle2018-03-142-1/+9
| | | | | | | | Change-Id: I8e2ece677268972d578a787467f7ef52a1f33a71 Differential revision: https://reviews.llvm.org/D44114 llvm-svn: 327496
* TableGen: Type-check BinOpsNicolai Haehnle2018-03-141-2/+6
| | | | | | | | | | | Additionally, allow more than two operands to !con, !add, !and, !or in the same way as is already allowed for !listconcat and !strconcat. Change-Id: I9659411f554201b90cd8ed7c7e004d381a66fa93 Differential revision: https://reviews.llvm.org/D44112 llvm-svn: 327494
* TableGen: Allow ? in listsNicolai Haehnle2018-03-141-3/+3
| | | | | | | | | | This makes using !dag more convenient in some cases. Change-Id: I0a8c35e15ccd1ecec778fd1c8d64eee38d74517c Differential revision: https://reviews.llvm.org/D44111 llvm-svn: 327493
* TableGen: Add !dag function for constructionNicolai Haehnle2018-03-142-1/+19
| | | | | | | | | | | | | | | This allows constructing DAG nodes with programmatically determined names, and can simplify constructing DAG nodes in other cases as well. Also, add documentation and some very simple tests for the already existing !con. Change-Id: Ida61cd82e99752548d7109ce8da34d29da56a5f7 Differential revision: https://reviews.llvm.org/D44110 llvm-svn: 327492
* Remove the LoopInstSimplify pass (-loop-instsimplify)Vedant Kumar2018-03-121-0/+2
| | | | | | | | | | | | LoopInstSimplify is unused and untested. Reading through the commit history the pass also seems to have a high maintenance burden. It would be best to retire the pass for now. It should be easy to recover if we need something similar in the future. Differential Revision: https://reviews.llvm.org/D44053 llvm-svn: 327329
* [AMDGPU][MC][DOC] Updated AMD GPU assembler descriptionDmitry Preobrazhensky2018-03-125-29/+5790
| | | | | | | | | See bug 36572: https://bugs.llvm.org/show_bug.cgi?id=36572 Differential Revision: https://reviews.llvm.org/D44020 Reviewers: artem.tamazov, vpykhtin llvm-svn: 327288
* Updating MIR Language Reference to include new syntax for symbols and physregs.Puyan Lotfi2018-03-121-32/+32
| | | | | | | External symbols now get the sigil '&' while physical registers get the sigil '$' for their prefix. llvm-svn: 327276
* [LangRef] make it clear that FP instructions do not have side effectsSanjay Patel2018-03-091-5/+20
| | | | | | | | | | | | | | | | | Also, fix the undef vs. UB example to use 'sdiv' because that can trigger div-by-zero UB. The existing text for the constrained intrinsics says: "By default, LLVM optimization passes assume that the rounding mode is round-to-nearest and that floating point exceptions will not be monitored. Constrained FP intrinsics are used to support non-default rounding modes and accurately preserve exception behavior without compromising LLVM’s ability to optimize FP code when the default behavior is used." ...so the additional text with the normal FP opcodes should make the different modes clear. Differential Revision: https://reviews.llvm.org/D44216 llvm-svn: 327138
* TableGen: Add a defset statementNicolai Haehnle2018-03-091-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | Allows capturing a list of concrete instantiated defs. This can be combined with foreach to create parallel sets of def instantiations with less repetition in the source. This purpose is largely also served by multiclasses, but in some cases multiclasses can't be used. The motivating example for this change is having a large set of intrinsics, which are generated from the IntrinsicsBackend.td file included by Intrinsics.td, and a corresponding set of instruction selection patterns, which are generated via the backend's .td files. Multiclasses cannot be used to eliminate the redundancy in this case, because a multiclass cannot span both LLVM's common .td files and the backend .td files at the same time. Change-Id: I879e35042dceea542a5e6776fad23c5e0e69e76b Differential revision: https://reviews.llvm.org/D44109 llvm-svn: 327121
* TableGen: Allow arbitrary list values as ranges of foreachNicolai Haehnle2018-03-091-2/+6
| | | | | | | | | The changes to FieldInit are required to make field references (Def.field) work inside a ForeachDeclaration: previously, Def.field wasn't resolved immediately when Def was already a fully resolved DefInit. Change-Id: I9875baec2fc5aac8c2b249e45b9cf18c65ae699b llvm-svn: 327120
* TableGen: add !isa operationNicolai Haehnle2018-03-092-0/+4
| | | | | | | | Change-Id: Iddb724c3ae706d82933a2d82c91d07e0e36b30e3 Differential revision: https://reviews.llvm.org/D44105 llvm-svn: 327117
* Use ellipsis ... to indicate omitted commandsEd Maste2018-03-081-2/+2
| | | | | | | | In an example like "clang -fxray-instrument .." the .. could be confused with a literal .. (parent directory), which is used in commands like "cmake -GNinja .." llvm-svn: 327000
* Add llvm-mca.rst to the table of contents in docs/CommandGuide.Andrea Di Biagio2018-03-081-0/+1
| | | | | | | This should fix the documentation error reported by builder llvm-sphinx-docs (build #16407) after r326998. llvm-svn: 326999
* [llvm-mca] LLVM Machine Code Analyzer.Andrea Di Biagio2018-03-081-0/+133
| | | | | | | | | | | | | | | | | | | | | | | | | | | llvm-mca is an LLVM based performance analysis tool that can be used to statically measure the performance of code, and to help triage potential problems with target scheduling models. llvm-mca uses information which is already available in LLVM (e.g. scheduling models) to statically measure the performance of machine code in a specific cpu. Performance is measured in terms of throughput as well as processor resource consumption. The tool currently works for processors with an out-of-order backend, for which there is a scheduling model available in LLVM. The main goal of this tool is not just to predict the performance of the code when run on the target, but also help with diagnosing potential performance issues. Given an assembly code sequence, llvm-mca estimates the IPC (instructions per cycle), as well as hardware resources pressure. The analysis and reporting style were mostly inspired by the IACA tool from Intel. This patch is related to the RFC on llvm-dev visible at this link: http://lists.llvm.org/pipermail/llvm-dev/2018-March/121490.html Differential Revision: https://reviews.llvm.org/D43951 llvm-svn: 326998
* [dsymutil] Embed toolchain in dSYM bundleJonas Devlieghere2018-03-081-0/+4
| | | | | | | | | Allow us to embed the (Xcode) toolchain in the dSYM bundle's property list. Differential revision: https://reviews.llvm.org/D44151 llvm-svn: 326994
* [AMDGPU] Update AMDGOUUsage.rst descriptionsTony Tye2018-03-081-27/+32
| | | | | | | | | - Improve description of XNACK ELF flag. - Rename all uses of wave to wavefront to be consistent. Differential Revision: https://reviews.llvm.org/D43983 llvm-svn: 326989
* [LangRef] fix formatting in FP descriptions; NFCSanjay Patel2018-03-071-21/+22
| | | | | | | | This is a clean-up step to reduce diffs ahead of real changes to the FP semantics as discussed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2018-February/121444.html llvm-svn: 326913
* TableGen: Add !foldl operationNicolai Haehnle2018-03-062-1/+10
| | | | | Change-Id: I63d67bf6e0b315e2d3360e47e3b62c9517f38987 llvm-svn: 326790
* TableGen: Allow !cast of records, cleanup conversion machineryNicolai Haehnle2018-03-061-4/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Distinguish two relationships between types: is-a and convertible-to. For example, a bit is not an int or vice versa, but they can be converted into each other (with range checks that you can think of as "dynamic": unlike other type checks, those range checks do not happen during parsing, but only once the final values have been established). Actually converting initializers between types is subtle: even when values of type A can be converted to type B (e.g. int into string), it may not be possible to do so with a concrete initializer (e.g., a VarInit that refers to a variable of type int cannot be immediately converted to a string). For this reason, distinguish between getCastTo and convertInitializerTo: the latter implements the actual conversion when appropriate, while the former will first try to do the actual conversion and fall back to introducing a !cast operation so that the conversion will be delayed until variable references have been resolved. To make the approach of adding !cast operations to work, !cast needs to fallback to convertInitializerTo when the special string <-> record logic does not apply. This enables casting records to a subclass, although that new functionality is only truly useful together with !isa, which will be added in a later change. The test is removed because it uses !srl on a bit sequence, which cannot really be supported consistently, but luckily isn't used anywhere either. Change-Id: I98168bf52649176654ed2ec61a29bdb29970cfe7 Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D43753 llvm-svn: 326785
* TableGen: Reimplement !foreach using the resolving mechanismNicolai Haehnle2018-03-051-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This changes the syntax of !foreach so that the first "parameter" is a new syntactic variable: !foreach(x, lst, expr) will define the variable x within the scope of expr, and evaluation of the !foreach will substitute elements of the given list (or dag) for x in expr. Aside from leading to a nicer syntax, this allows more complex expressions where x is deeply nested, or even constant expressions in which x does not occur at all. !foreach is currently not actually used anywhere in trunk, but I plan to use it in the AMDGPU backend. If out-of-tree targets are using it, they can adjust to the new syntax very easily. Change-Id: Ib966694d8ab6542279d6bc358b6f4d767945a805 Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits, tpr Differential Revision: https://reviews.llvm.org/D43651 llvm-svn: 326705
* [Docs] Add LLVM for Grad Students to Contributing page.Florian Hahn2018-03-021-5/+10
| | | | | | | | | | | | | | Adrian Sampson's blog post provides a good and relatively up-do-date introduction to LLVM. I think this post could be helpful for people wanting to get started with LLVM. Reviewers: asb, tonic, silvas, probinson, kristof.beyls, rengolin Reviewed By: rengolin Differential Revision: https://reviews.llvm.org/D42904 llvm-svn: 326576
* [AArch64] Add support for secrel add/load/store relocations for COFFMartin Storsjo2018-03-011-0/+24
| | | | | | Differential Revision: https://reviews.llvm.org/D43288 llvm-svn: 326480
* build: add the ability to create a symlink for dsymutilSaleem Abdulrasool2018-02-281-0/+4
| | | | | | | | | Add a `LLVM_INSTALL_CCTOOLS_SYMLINKS` to mirror `LLVM_INSTALL_BINUTILS_SYMLINKS`. For now, this allows us to create symlinks for `dsymutil` to `llvm-dsymutil`. This option is off by default, but the user can enable it. llvm-svn: 326381
* [DebugInfo] Support DWARF v5 source code embedding extensionScott Linder2018-02-231-4/+54
| | | | | | | | | | | | | | | | | | | In DWARF v5 the Line Number Program Header is extensible, allowing values with new content types. In this extension a content type is added, DW_LNCT_LLVM_source, which contains the embedded source code of the file. Add new optional attribute for !DIFile IR metadata called source which contains source text. Use this to output the source to the DWARF line table of code objects. Analogously extend METADATA_FILE in Bitcode and .file directive in ASM to support optional source. Teach llvm-dwarfdump and llvm-objdump about the new values. Update the output format of llvm-dwarfdump to make room for the new attribute on file_names entries, and support embedded sources for the -source option in llvm-objdump. Differential Revision: https://reviews.llvm.org/D42765 llvm-svn: 325970
* Support for the mno-stack-arg-probe flagHans Wennborg2018-02-231-0/+2
| | | | | | | | | | | | Adds support for this flag. There is also another piece for clang (separate review). More info: https://bugs.llvm.org/show_bug.cgi?id=36221 By Ruslan Nikolaev! Differential Revision: https://reviews.llvm.org/D43107 llvm-svn: 325900
* TableGen: Add !size operationNicolai Haehnle2018-02-232-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Returns the size of a list. I have found this to be rather useful in some development for the AMDGPU backend where we could simplify our .td files by concatenating list<LLVMType> for complex intrinsics. Doing so requires us to compute the position argument for LLVMMatchType. Basically, the usage is in a pattern that looks somewhat like this: list<LLVMType> argtypes = !listconcat(base, [llvm_any_ty, LLVMMatchType<!size(base)>]); Change-Id: I360a0b000fd488d18bea412228230fd93722bd2c Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits, tpr Differential Revision: https://reviews.llvm.org/D43553 llvm-svn: 325883
* [libFuzzer] Include TEMP_MAX_LEN in Fuzzer::PrintStats.Matt Morehouse2018-02-221-2/+4
| | | | | | | | | | | | Reviewers: kcc Reviewed By: kcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43597 llvm-svn: 325817
* Add default address space for functions to the data layout (1/3)Dylan McKay2018-02-191-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This adds initial support for letting targets specify which address spaces their functions should reside in by default. If a function is created by a frontend, it will get the default address space specified in the DataLayout, unless the frontend explicitly uses a more general `llvm::Function` constructor. Function address spaces will become a part of the bitcode and textual IR forms, as we do not have access to a data layout whilst parsing LL. It will be possible to write IR that explicitly has `addrspace(n)` on a function. In this case, the function will reside in the specified space, ignoring the default in the DL. This is the first step towards placing functions into the correct address space for Harvard architectures. Full patchset * Add program address space to data layout D37052 * Require address space to be specified when creating functions D37054 * [clang] Require address space to be specified when creating functions D37057 Reviewers: pcc, arsenm, kparzysz, hfinkel, theraven Reviewed By: theraven Subscribers: arichardson, simoncook, rengolin, wdng, uabelho, bjope, asb, llvm-commits Differential Revision: https://reviews.llvm.org/D37052 llvm-svn: 325479
* AMDGPU: Bring elf flags in sync with the specKonstantin Zhuravlyov2018-02-161-41/+44
| | | | | | | | | | | - Add MACH flags - Add XNACK flag - Add reserved flags - Minor cleanups in docs Differential Revision: https://reviews.llvm.org/D43356 llvm-svn: 325399
* [ARM] Allow 64- and 128-bit types with 't' inline asm constraintPablo Barrio2018-02-151-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In LLVM, 't' selects a floating-point/SIMD register and only supports 32-bit values. This is appropriately documented in the LLVM Language Reference Manual. However, this behaviour diverges from that of GCC, where 't' selects the s0-s31 registers and its qX and dX variants depending on additional operand modifiers (q/P). For example, the following C code: #include <arm_neon.h> float32x4_t a, b, x; asm("vadd.f32 %0, %1, %2" : "=t" (x) : "t" (a), "t" (b)) results in the following assembly if compiled with GCC: vadd.f32 s0, s0, s1 whereas LLVM will show "error: couldn't allocate output register for constraint 't'", since a, b, x are 128-bit variables, not 32-bit. This patch extends the use of 't' to mean that of GCC, thus allowing selection of the lower Q vector regs and their D/S variants. For example, the earlier code will now compile as: vadd.f32 q0, q0, q1 This behaviour still differs from that of GCC but I think it is actually more correct, since LLVM picks up the right register type based on the datatype of x, while GCC would need an extra operand modifier to achieve the same result, as follows: asm("vadd.f32 %q0, %q1, %q2" : "=t" (x) : "t" (a), "t" (b)) Since this is only an extension of functionality, existing code should not be affected by this change. Note that operand modifiers q/P are already supported by LLVM, so this patch should suffice to support inline assembly with constraint 't' originally built for GCC. Reviewers: grosbach, rengolin Reviewed By: rengolin Subscribers: rogfer01, efriedma, olista01, aemerson, javed.absar, eraman, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D42962 llvm-svn: 325244
* Adding a width of the GEP index to the Data Layout.Elena Demikhovsky2018-02-141-23/+24
| | | | | | | | | | | | | | | | | | Making a width of GEP Index, which is used for address calculation, to be one of the pointer properties in the Data Layout. p[address space]:size:memory_size:alignment:pref_alignment:index_size_in_bits. The index size parameter is optional, if not specified, it is equal to the pointer size. Till now, the InstCombiner normalized GEPs and extended the Index operand to the pointer width. It works fine if you can convert pointer to integer for address calculation and all registered targets do this. But some ISAs have very restricted instruction set for the pointer calculation. During discussions were desided to retrieve information for GEP index from the Data Layout. http://lists.llvm.org/pipermail/llvm-dev/2018-January/120416.html I added an interface to the Data Layout and I changed the InstCombiner and some other passes to take the Index width into account. This change does not affect any in-tree target. I added tests to cover data layouts with explicitly specified index size. Differential Revision: https://reviews.llvm.org/D42123 llvm-svn: 325102
* [AMDGPU] Change constant addr space to 4Yaxun Liu2018-02-131-20/+10
| | | | | | Differential Revision: https://reviews.llvm.org/D43170 llvm-svn: 325030
* Reapply "AMDGPU: Add 32-bit constant address space"Matt Arsenault2018-02-091-0/+1
| | | | | | This reverts r324494 and reapplies r324487. llvm-svn: 324747
* [AMDGPU] Updae documentation about address spaceYaxun Liu2018-02-081-25/+13
| | | | llvm-svn: 324617
* Re-land [dsymutil] Upstream update featureJonas Devlieghere2018-02-081-1/+9
| | | | | | | | | | This commit attempts to re-land the r324480 which was reverted in r324493 because it broke the Windows bots. For now I disabled the two update tests on Windows until I'm able to debug this. Differential revision: https://reviews.llvm.org/D42880 llvm-svn: 324592
* Revert "AMDGPU: Add 32-bit constant address space"Rafael Espindola2018-02-071-1/+0
| | | | | | | | This reverts commit r324487. It broke clang tests. llvm-svn: 324494
* Revert dsymutil -update commitsJonas Devlieghere2018-02-071-9/+1
| | | | | | | Revert "[dsymutil][test] Check the updated dSYM instead of companion file." Revert "[dsymutil] Upstream update feature." llvm-svn: 324493
* AMDGPU: Add 32-bit constant address spaceMarek Olsak2018-02-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Note: This is a candidate for LLVM 6.0, because it was planned to be in that release but was delayed due to a long review period. Merge conflict in release_60 - resolution: Add "-p6:32:32" into the second (non-amdgiz) string. Only scalar loads support 32-bit pointers. An address in a VGPR will fail to compile. That's OK because the results of loads will only be used in places where VGPRs are forbidden. Updated AMDGPUAliasAnalysis and used SReg_64_XEXEC. The tests cover all uses cases we need for Mesa. Reviewers: arsenm, nhaehnle Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits Differential Revision: https://reviews.llvm.org/D41651 llvm-svn: 324487
* [dsymutil] Upstream update feature.Jonas Devlieghere2018-02-071-1/+9
| | | | | | | | | | | Now that dsymutil can generate accelerator tables, we can upstream the update logic that, as the name implies, updates the accelerator tables in an existing dSYM bundle. In combination with `-minimize` this can be used to remove redundant .debug_(inlines|pubtypes|pubnames). Differential revision: https://reviews.llvm.org/D42880 llvm-svn: 324480
OpenPOWER on IntegriCloud