summaryrefslogtreecommitdiffstats
path: root/llvm/docs
Commit message (Collapse)AuthorAgeFilesLines
* Add a proposal for a libc project under the LLVM umbrella.Siva Chandra2019-08-151-0/+125
| | | | | | | | | | | | Reviewers: chandlerc, dlj, echristo, hfinkel, jfb, zturner Subscribers: dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64939 llvm-svn: 369012
* Add ptrmask intrinsicFlorian Hahn2019-08-151-0/+36
| | | | | | | | | | | | | | | | | | | This patch adds a ptrmask intrinsic which allows masking out bits of a pointer that must be zero when accessing it, because of ABI alignment requirements or a restriction of the meaningful bits of a pointer through the data layout. This avoids doing a ptrtoint/inttoptr round trip in some cases (e.g. tagged pointers) and allows us to not lose information about the underlying object. Reviewers: nlopes, efriedma, hfinkel, sanjoy, jdoerfert, aqjune Reviewed by: sanjoy, jdoerfert Differential Revision: https://reviews.llvm.org/D59065 llvm-svn: 368986
* [llvm-objcopy] Allow 'protected' visibility to be set when usingChris Jackson2019-08-151-0/+1
| | | | | | | | | | add-symbol Reviewers: Maskray, rupprecht Differential Revision: https://reviews.llvm.org/D65891 llvm-svn: 368982
* [docs] Fix sphinx doc generation errorsJordan Rupprecht2019-08-146-21/+31
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Errors fixed: - GettingStarted: Duplicate explicit target name: "cmake" - GlobalISel: Unexpected indentation - LoopTerminology: Explicit markup ends without a blank line; unexpected unindent - ORCv2: Definition list ends without a blank line; unexpected unindent - Misc: document isn't included in any toctree Verified that a clean docs build (`rm -rf docs/ && ninja docs-llvm-html`) passes with no errors. Spot checked the individual pages to make sure they look OK. Reviewers: thakis, dsanders Reviewed By: dsanders Subscribers: arphaman, llvm-commits, lhames, rovka, dsanders, reames Tags: #llvm Differential Revision: https://reviews.llvm.org/D66183 llvm-svn: 368932
* Add support in CMake to statically link the C++ standard library.Erich Keane2019-08-141-0/+5
| | | | | | | | | | | | | | | It is sometimes useful to have the C++ standard library linked into the assembly when compiling clang, particularly when distributing a compiler onto systems that don't have a copy of stdlibc++ or libc++ installed. This functionality should work with either GCC or Clang as the host compiler, though statically linking libc++ (as may be required for licensing purposes) is only possible if the host compiler is Clang with a copy of libc++ available. Differential Revision: https://reviews.llvm.org/D65603 llvm-svn: 368907
* Move to C++14JF Bastien2019-08-141-96/+8
| | | | | | | | | | | | | | | Summary: I just bumped the minimum compiler versions to support C++14 in D66188. Following [our process](http://llvm.org/docs/DeveloperPolicy.html#toolchain) and [our previous agreement](http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html), I'm now officially bumping the C++ version to 14 and updating the documentation. Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, chandlerc, thakis, EricWF, jyknight, lhames, JDevlieghere Tags: #llvm Differential Revision: https://reviews.llvm.org/D66195 llvm-svn: 368887
* [LangRef] Remove opening [ that was missing a closing ] from ↵Craig Topper2019-08-141-3/+3
| | | | | | | | | call/callbr/invoke syntax. It looks like this bracket was added when the addrspace was added. before it. So I think it can jut be removed. llvm-svn: 368861
* Remove minimum toolchain soft-errorJF Bastien2019-08-141-9/+0
| | | | | | | | | | | | | | | | | | | | | | | Summary: Back in January I changed the minimum toolchain version required to build clang and LLVM: D57264. Since then we've release LLVM 8, following [our process](http://llvm.org/docs/DeveloperPolicy.html#toolchain) it's therefore now a good time to remove the soft-error and officially deprecate older toolchains. I tried this out last Tursday night to see if any bots complained, and I saw no complaints. I also manually audited bots and didn't see any bot that should break, but their toolchain information is unreliable and some bots are offline. Once this patch stick we'll move to C++14 as we've [already agreed](http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html). Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, EricWF, thakis, chandlerc Tags: #llvm Differential Revision: https://reviews.llvm.org/D66188 llvm-svn: 368799
* Extend coroutines to support a "returned continuation" lowering.John McCall2019-08-141-31/+272
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A quick contrast of this ABI with the currently-implemented ABI: - Allocation is implicitly managed by the lowering passes, which is fine for frontends that are fine with assuming that allocation cannot fail. This assumption is necessary to implement dynamic allocas anyway. - The lowering attempts to fit the coroutine frame into an opaque, statically-sized buffer before falling back on allocation; the same buffer must be provided to every resume point. A buffer must be at least pointer-sized. - The resume and destroy functions have been combined; the continuation function takes a parameter indicating whether it has succeeded. - Conversely, every suspend point begins its own continuation function. - The continuation function pointer is directly returned to the caller instead of being stored in the frame. The continuation can therefore directly destroy the frame when exiting the coroutine instead of having to leave it in a defunct state. - Other values can be returned directly to the caller instead of going through a promise allocation. The frontend provides a "prototype" function declaration from which the type, calling convention, and attributes of the continuation functions are taken. - On the caller side, the frontend can generate natural IR that directly uses the continuation functions as long as it prevents IPO with the coroutine until lowering has happened. In combination with the point above, the frontend is almost totally in charge of the ABI of the coroutine. - Unique-yield coroutines are given some special treatment. llvm-svn: 368788
* [Bugpoint redesign] Fix nonlocal URI link in docDiego Trevino Ferrer2019-08-091-8/+5
| | | | | | | | | | | | | | Summary: Fixes documentation bot build http://lab.llvm.org:8011/builders/llvm-sphinx-docs Reviewers: JDevlieghere Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66022 llvm-svn: 368493
* [Docs][llvm-strip] Fix an indentation issue.Michael Pozulp2019-08-091-1/+1
| | | | llvm-svn: 368473
* [Docs][llvm-strip] Add help text to llvm-strip rst docMichael Pozulp2019-08-092-16/+167
| | | | | | | | | | | | | | | | Summary: Addresses https://bugs.llvm.org/show_bug.cgi?id=42383 Reviewers: jhenderson, alexshap, rupprecht Reviewed By: jhenderson Subscribers: wolfgangp, jakehehrlich, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65384 llvm-svn: 368464
* [MCA] Add flag -show-encoding to llvm-mca.Andrea Di Biagio2019-08-091-4/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Flag -show-encoding enables the printing of instruction encodings as part of the the instruction info view. Example (with flags -mtriple=x86_64-- -mcpu=btver2): Instruction Info: [1]: #uOps [2]: Latency [3]: RThroughput [4]: MayLoad [5]: MayStore [6]: HasSideEffects (U) [7]: Encoding Size [1] [2] [3] [4] [5] [6] [7] Encodings: Instructions: 1 2 1.00 4 c5 f0 59 d0 vmulps %xmm0, %xmm1, %xmm2 1 4 1.00 4 c5 eb 7c da vhaddps %xmm2, %xmm2, %xmm3 1 4 1.00 4 c5 e3 7c e3 vhaddps %xmm3, %xmm3, %xmm4 In this example, column Encoding Size is the size in bytes of the instruction encoding. Column Encodings reports the actual instruction encodings as byte sequences in hex (objdump style). The computation of encodings is done by a utility class named mca::CodeEmitter. In future, I plan to expose the CodeEmitter to the instruction builder, so that information about instruction encoding sizes can be used by the simulator. That would be a first step towards simulating the throughput from the decoders in the hardware frontend. Differential Revision: https://reviews.llvm.org/D65948 llvm-svn: 368432
* Added Delta IR Reduction ToolDiego Trevino Ferrer2019-08-081-0/+105
| | | | | | | | | | | | | | | | Summary: Tool parses input IR file, and runs the delta debugging algorithm to reduce the functions inside the input file. Reviewers: alexshap, chandlerc Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63672 > llvm-svn: 368071 llvm-svn: 368358
* [globalisel][legalizer] Attempt to write down the minimal legalization rulesDaniel Sanders2019-08-081-0/+95
| | | | | | | | | | | | | | | | | | | Summary: There aren't very many requirements on the legalization rules but we should document them. Reviewers: aditya_nandakumar, volkan, bogner, paquette, aemerson, rovka, arsenm, Petar.Avramovic Subscribers: wdng, kristof.beyls, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62423 # Conflicts: # llvm/docs/GlobalISel.rst llvm-svn: 368321
* Add llvm.licm.disable metadataTim Corringham2019-08-081-2/+16
| | | | | | | | | | | | | | For some targets the LICM pass can result in sub-optimal code in some cases where it would be better not to run the pass, but it isn't always possible to suppress the transformations heuristically. Where the front-end has insight into such cases it is beneficial to attach loop metadata to disable the pass - this change adds the llvm.licm.disable metadata to enable that. Differential Revision: https://reviews.llvm.org/D64557 llvm-svn: 368296
* [llvm-lipo] Update llvm-lipo docs for -info -thin -create -replace -segalign ↵Anusha Basana2019-08-071-3/+35
| | | | | | | | | | | | | | | | | | | flags Summary: The information for -info -thin -create -replace and -segalign flags are added to llvm-lipo.rst Test Plan: Reviewers: smeenai, alexshap, compnerd, mtrent Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65676 llvm-svn: 368235
* Revert Added Delta IR Reduction ToolDiego Trevino Ferrer2019-08-071-105/+0
| | | | | | This reverts r368071 (git commit a2584978f5bb41973d65a145b0d9459b81e3ac6d) llvm-svn: 368217
* Added Delta IR Reduction ToolDiego Trevino Ferrer2019-08-071-0/+105
| | | | | | | | | | | | | | | | Summary: Tool parses input IR file, and runs the delta debugging algorithm to reduce the functions inside the input file. Reviewers: alexshap, chandlerc Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63672 > llvm-svn: 368071 llvm-svn: 368214
* [RISCV][NFC] Document RISC-V-specific assembly constraintsSam Elliott2019-08-071-0/+11
| | | | llvm-svn: 368167
* Reverts commit r368117, r368115 and r368112Petr Hosek2019-08-071-106/+0
| | | | | | | | | | | | This reverts commits: "Added Delta IR Reduction Tool" "[Bugpoint redesign] Added Pass to Remove Global Variables" "Added Tool as Dependency to tests & fixed warnings" Reduce/remove-funcs.ll is failing on bots. llvm-svn: 368122
* Added Delta IR Reduction ToolDiego Trevino Ferrer2019-08-071-0/+106
| | | | | | | | | | | | | | | | Summary: Tool parses input IR file, and runs the delta debugging algorithm to reduce the functions inside the input file. Reviewers: alexshap, chandlerc Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63672 > llvm-svn: 368071 llvm-svn: 368112
* Revert "Added Delta IR Reduction Tool"Dmitri Gribenko2019-08-061-106/+0
| | | | | | This reverts commit r368071, it broke buildbots. llvm-svn: 368073
* Added Delta IR Reduction ToolDiego Trevino Ferrer2019-08-061-0/+106
| | | | | | | | | | | | | | Summary: Tool parses input IR file, and runs the delta debugging algorithm to reduce the functions inside the input file. Reviewers: alexshap, chandlerc Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63672 llvm-svn: 368071
* Revert r367941 "Add a note to the release not about a potentially breaking ↵Hans Wennborg2019-08-061-13/+0
| | | | | | | | optimization" The note was moved to the release_90 branch in r367997. llvm-svn: 367998
* [Attributor] Deduce the "no-return" attribute for functionsJohannes Doerfert2019-08-051-2/+3
| | | | | | | | | | | | | | | A function is "no-return" if we never reach a return instruction, either because there are none or the ones that exist are dead. Test have been adjusted: - either noreturn was added, or - noreturn was avoided by modifying the code. The new noreturn_{sync,async} test make sure we do handle invoke instructions with a noreturn (and potentially nowunwind) callee correctly, even in the presence of potential asynchronous exceptions. llvm-svn: 367948
* [llvm-readelf] Support dumping of stack sizes sections with readelf ↵Wolfgang Pieb2019-08-051-0/+5
| | | | | | | | | | --stack-sizes Reviewers: jhenderson, grimar, rupprecht Differential Revision: https://reviews.llvm.org/D65313 llvm-svn: 367942
* Add a note to the release not about a potentially breaking optimizationPhilip Reames2019-08-051-0/+13
| | | | | | This has come up twice already (once in pr42763 and once in the commit thread), so give warning of a new way in which UB can result in unexpected program behavior. llvm-svn: 367941
* [MCA][doc] Add a section for the 'Bottleneck Analysis'.Andrea Di Biagio2019-08-051-6/+79
| | | | | | Also clarify the meaning of 'Block RThroughput' and 'RThroughput'. llvm-svn: 367853
* Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFCFangrui Song2019-08-051-1/+1
| | | | | | F_{None,Text,Append} are kept for compatibility since r334221. llvm-svn: 367800
* IR: print value numbers for unnamed function argumentsTim Northover2019-08-031-0/+7
| | | | | | | | | | For consistency with normal instructions and clarity when reading IR, it's best to print the %0, %1, ... names of function arguments in definitions. Also modifies the parser to accept IR in that form for obvious reasons. llvm-svn: 367755
* [BPF] annotate DIType metadata for builtin preseve_array_access_index()Yonghong Song2019-08-021-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, debuginfo types are annotated to IR builtin preserve_struct_access_index() and preserve_union_access_index(), but not preserve_array_access_index(). The debug info is useful to identify the root type name which later will be used for type comparison. For user access without explicit type conversions, the previous scheme works as we can ignore intermediate compiler generated type conversions (e.g., from union types to union members) and still generate correct access index string. The issue comes with user explicit type conversions, e.g., converting an array to a structure like below: struct t { int a; char b[40]; }; struct p { int c; int d; }; struct t *var = ...; ... __builtin_preserve_access_index(&(((struct p *)&(var->b[0]))->d)) ... Although BPF backend can derive the type of &(var->b[0]), explicit type annotation make checking more consistent and less error prone. Another benefit is for multiple dimension array handling. For example, struct p { int c; int d; } g[8][9][10]; ... __builtin_preserve_access_index(&g[2][3][4].d) ... It would be possible to calculate the number of "struct p"'s before accessing its member "d" if array debug info is available as it contains each dimension range. This patch enables to annotate IR builtin preserve_array_access_index() with proper debuginfo type. The unit test case and language reference is updated as well. Signed-off-by: Yonghong Song <yhs@fb.com> Differential Revision: https://reviews.llvm.org/D65664 llvm-svn: 367724
* [doc] Give a workaround for a FileCheck regex that ends in a brace.Paul Robinson2019-08-021-1/+4
| | | | | | Addresses PR42864. llvm-svn: 367689
* [ORC] Change the locking scheme for ThreadSafeModule.Lang Hames2019-08-021-28/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ThreadSafeModule/ThreadSafeContext are used to manage lifetimes and locking for LLVMContexts in ORCv2. Prior to this patch contexts were locked as soon as an associated Module was emitted (to be compiled and linked), and were not unlocked until the emit call returned. This could lead to deadlocks if interdependent modules that shared contexts were compiled on different threads: when, during emission of the first module, the dependence was discovered the second module (which would provide the required symbol) could not be emitted as the thread emitting the first module still held the lock. This patch eliminates this possibility by moving to a finer-grained locking scheme. Each client holds the module lock only while they are actively operating on it. To make this finer grained locking simpler/safer to implement this patch removes the explicit lock method, 'getContextLock', from ThreadSafeModule and replaces it with a new method, 'withModuleDo', that implicitly locks the context, calls a user-supplied function object to operate on the Module, then implicitly unlocks the context before returning the result. ThreadSafeModule TSM = getModule(...); size_t NumFunctions = TSM.withModuleDo( [](Module &M) { // <- context locked before entry to lambda. return M.size(); }); Existing ORCv2 layers that operate on ThreadSafeModules are updated to use the new method. This method is used to introduce Module locking into each of the existing layers. llvm-svn: 367686
* [MCA] Add support for printing immedate values as hex. Also enable lexing of ↵Andrea Di Biagio2019-08-021-0/+5
| | | | | | | | | | | | | | | | | | masm binary and hex literals. This patch adds a new llvm-mca flag named -print-imm-hex. By default, the instruction printer prints immediate operands as decimals. Flag -print-imm-hex enables the instruction printer to print those operands in hex. This patch also adds support for MASM binary and hex literal numbers (example 0FFh, 101b). Added tests to verify the behavior of the new flag. Tests also verify that masm numeric literal operands are now recognized. Differential Revision: https://reviews.llvm.org/D65588 llvm-svn: 367671
* CodeGen: Allow virtual registers in bundlesMatt Arsenault2019-08-011-9/+12
| | | | | | | | | | | | | | | The note in the documentation suggests this restriction is a compile time optimization for architectures that make heavy use of bundling. Allowing virtual registers in a bundle is useful for some (non-R600) AMDGPU use cases and are infrequent enough to matter. A more common AMDGPU use case has already been using virtual registers in bundles since r333691, although never calling finalizeBundle on them and manually creating the use/def list on the BUNDLE instruction. This is also relatively infrequent, and only happens for consecutive sequences of some load/store types. llvm-svn: 367597
* Fix spacing of LLVM_USE_PERF in CMake.rst that caused it to be tabbed in funnyErich Keane2019-08-011-1/+1
| | | | llvm-svn: 367585
* Document LLVM_ENABLE_LIBCXX in CMake.rstErich Keane2019-08-011-0/+5
| | | | llvm-svn: 367584
* Attempt to unbreak sphinx build bot by inserting a link.Philip Reames2019-07-312-3/+4
| | | | llvm-svn: 367487
* [docs] Add references to unreferenced footnotes.Lang Hames2019-07-311-13/+13
| | | | | | Thanks to Stefan Granitz for catching the issue. llvm-svn: 367458
* Reland "[DwarfDebug] Dump call site debug info"Djordje Todorovic2019-07-311-0/+4
| | | | | | | | | The build failure found after the rL365467 has been resolved. Differential Revision: https://reviews.llvm.org/D60716 llvm-svn: 367446
* [docs][FIX] Add missing word to documentation in terms of SCCsJohannes Doerfert2019-07-311-1/+1
| | | | | | | | In the approval of D65299, commited as rL367440, I mentioned that my proposed wording was lacking the word "maximal". It is added now for correctness. llvm-svn: 367445
* [build] Add the ability to create a symlink for lipoAnusha Basana2019-07-311-0/+4
| | | | | | | | | Add user enabled option to create lipo with symlink to llvm-lipo Used rL326381 for reference. Differential Revision: https://reviews.llvm.org/D65477 llvm-svn: 367444
* [docs] Reword documentation in terms of SCCs not cyclesPhilip Reames2019-07-311-8/+15
| | | | | | | | | | | | | | Given the example: header: br i1 %c, label %next, label %header next: br i1 %c2, label %exit, label %header We end up with a loop containing both header and next. Given that, the describing the loop in terms of cycles is confusing since we have multiple distinct cycles within a single Loop. Standardize on the SCC to clarify. Differential Revision: https://reviews.llvm.org/D65299 llvm-svn: 367440
* [docs] Add cmake to Software requirementsDiana Picus2019-07-311-1/+3
| | | | | | | | | Add cmake to the list of packages required for compiling LLVM. Also move make to the bottom of the list and mark it as optional. Differential Revision: https://reviews.llvm.org/D65438 llvm-svn: 367395
* [NFC] Remove LLVM_ALIGNASJF Bastien2019-07-311-1/+1
| | | | | | | | | | | | | | Summary: The minimum compilers support all have alignas, and we don't use LLVM_ALIGNAS anywhere anymore. This also removes an MSVC diagnostic which, according to the comment above, isn't relevant anymore. Reviewers: rnk Subscribers: mgorny, jkorous, dexonsmith, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D65458 llvm-svn: 367383
* Reland: [Remarks] Add an LLVM-bitstream-based remark serializerFrancis Visoiu Mistrih2019-07-311-0/+245
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new serializer, using a binary format based on the LLVM bitstream format. This format provides a way to serialize the remarks in two modes: 1) Separate mode: the metadata is separate from the remark entries. 2) Standalone mode: the metadata and the remark entries are in the same file. The format contains: * a meta block: container version, container type, string table, external file path, remark version * a remark block: type, remark name, pass name, function name, debug file, debug line, debug column, hotness, arguments (key, value, debug file, debug line, debug column) A string table is required for this format, which will be dumped in the meta block to be consumed before parsing the remark blocks. On clang itself, we noticed a size reduction of 13.4x compared to YAML, and a compile-time reduction of between 1.7% and 3.5% on CTMark. Differential Revision: https://reviews.llvm.org/D63466 Original llvm-svn: 367364 Revert llvm-svn: 367370 llvm-svn: 367372
* Revert "[Remarks] Add an LLVM-bitstream-based remark serializer"Francis Visoiu Mistrih2019-07-311-245/+0
| | | | | | | | This reverts commit r367364. Breaks some bots: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-gn/builds/3161/steps/annotate/logs/stdio llvm-svn: 367370
* [Remarks] Add an LLVM-bitstream-based remark serializerFrancis Visoiu Mistrih2019-07-301-0/+245
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new serializer, using a binary format based on the LLVM bitstream format. This format provides a way to serialize the remarks in two modes: 1) Separate mode: the metadata is separate from the remark entries. 2) Standalone mode: the metadata and the remark entries are in the same file. The format contains: * a meta block: container version, container type, string table, external file path, remark version * a remark block: type, remark name, pass name, function name, debug file, debug line, debug column, hotness, arguments (key, value, debug file, debug line, debug column) A string table is required for this format, which will be dumped in the meta block to be consumed before parsing the remark blocks. On clang itself, we noticed a size reduction of 13.4x compared to YAML, and a compile-time reduction of between 1.7% and 3.5% on CTMark. Differential Revision: https://reviews.llvm.org/D63466 llvm-svn: 367364
* [WebAssembly] Do not emit tail calls with return type mismatchThomas Lively2019-07-301-3/+8
| | | | | | | | | | | | | | | | | Summary: return_call and return_call_indirect are only valid if the return types of the callee and caller match. We were previously not enforcing that, which was producing invalid modules. Reviewers: aheejin Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65246 llvm-svn: 367339
OpenPOWER on IntegriCloud