summaryrefslogtreecommitdiffstats
path: root/llvm/docs
Commit message (Collapse)AuthorAgeFilesLines
* [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
* [Docs] Fix sphinx warning in OCamlLangImpl5.rstFrancis Visoiu Mistrih2019-07-301-1/+1
| | | | | | | | | | The path to the image was outdated. http://lab.llvm.org:8011/builders/llvm-sphinx-docs/builds/33865/steps/docs-llvm-html/logs/stdio llvm/docs/tutorial/OCamlLangImpl5.rst:173: WARNING: image file not readable: tutorial/LangImpl05-cfg.png llvm-svn: 367334
* [Remarks] Add two serialization modes for remarks: separate and standaloneFrancis Visoiu Mistrih2019-07-301-0/+20
| | | | | | | | | | The default mode is separate, where the metadata is serialized separately from the remarks. Another mode is the standalone mode, where the metadata is serialized before the remarks, on the same stream. llvm-svn: 367328
* Reland: [Remarks] Support parsing remark metadata in the YAML remark parserFrancis Visoiu Mistrih2019-07-261-9/+24
| | | | | | | | | | | | | | | | This adds support to the yaml remark parser to be able to parse remarks directly from the metadata. This supports parsing separate metadata and following the external file with the associated metadata, and also a standalone file containing metadata + remarks all together. Original llvm-svn: 367148 Revert llvm-svn: 367151 This has a fix for gcc builds. llvm-svn: 367155
* Revert "[Remarks] Support parsing remark metadata in the YAML remark parser"Francis Visoiu Mistrih2019-07-261-24/+9
| | | | | | | | | This reverts r367148. Seems to fail on http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fuzzer/builds/27768. llvm-svn: 367151
* [Remarks] Support parsing remark metadata in the YAML remark parserFrancis Visoiu Mistrih2019-07-261-9/+24
| | | | | | | | | | | This adds support to the yaml remark parser to be able to parse remarks directly from the metadata. This supports parsing separate metadata and following the external file with the associated metadata, and also a standalone file containing metadata + remarks all together. llvm-svn: 367148
* [llvm-objcopy] Add support for --add-section for COFFSergey Dmitriev2019-07-261-7/+7
| | | | | | | | This patch enables support for --add-section=... option for COFF objects. Differential Revision: https://reviews.llvm.org/D65040 llvm-svn: 367130
* [Clang] New loop pragma vectorize_predicateSjoerd Meijer2019-07-251-0/+15
| | | | | | | | | | | | | | | | | | | This adds a new vectorize predication loop hint: #pragma clang loop vectorize_predicate(enable) that can be used to indicate to the vectoriser that all (load/store) instructions should be predicated (masked). This allows, for example, folding of the remainder loop into the main loop. This patch will be followed up with D64916 and D65197. The former is a refactoring in the loopvectorizer and the groundwork to make tail loop folding a more general concept, and in the latter the actual tail loop folding transformation will be implemented. Differential Revision: https://reviews.llvm.org/D64744 llvm-svn: 366989
* [docs] Split out a section on LoopInfo in the new loop documentationPhilip Reames2019-07-241-6/+37
| | | | llvm-svn: 366964
* Apply a few more reviewer suggestions from D65164Philip Reames2019-07-241-6/+11
| | | | llvm-svn: 366961
* Define some basic terminology around loops in our documentationPhilip Reames2019-07-241-0/+110
| | | | | | | | | | | | I've noticed a lot of confusion around this area recently with key terms being misused in a number of threads. To help reign that in, let's go ahead and document the current terminology and meaning thereof. My hope is to grow this over time into a broader discussion of canonical loop forms - yes, there are more than one ... many more than one - but for the moment, simply having the key terminology is a good stopping place. Note: I am landing this *without* an LGTM. All feedback so far has been positive, and trying to apply all of the suggested changes/extensions would cause the review to never end. Instead, I decided to land it with the obvious fixes made based on reviewer comments, then iterate from there. Differential Revision: https://reviews.llvm.org/D65164 llvm-svn: 366960
* FileCheck [8/12]: Define numeric var from exprThomas Preud'homme2019-07-241-5/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch is part of a patch series to add support for FileCheck numeric expressions. This specific patch lift the restriction for a numeric expression to either be a variable definition or a numeric expression to try to match. This commit allows a numeric variable to be set to the result of the evaluation of a numeric expression after it has been matched successfully. When it happens, the variable is allowed to be used on the same line since its value is known at match time. It also makes use of this possibility to reuse the parsing code to parse a command-line definition by crafting a mirror string of the -D option with the equal sign replaced by a colon sign, e.g. for option '-D#NUMVAL=10' it creates the string '-D#NUMVAL=10 (parsed as [[#NUMVAL:10]])' where the numeric expression is parsed to define NUMVAL. This result in a few tests needing updating for the location diagnostics on top of the tests for the new feature. It also enables empty numeric expression which match any number without defining a variable. This is done here rather than in commit #5 of the patch series because it requires to dissociate automatic regex insertion in RegExStr from variable definition which would make commit #5 even bigger than it already is. Copyright: - Linaro (changes up to diff 183612 of revision D55940) - GraphCore (changes in later versions of revision D55940 and in new revision created off D55940) Reviewers: jhenderson, chandlerc, jdenny, probinson, grimar, arichardson, rnk Subscribers: hiraditya, llvm-commits, probinson, dblaikie, grimar, arichardson, tra, rnk, kristina, hfinkel, rogfer01, JonChesterfield Tags: #llvm Differential Revision: https://reviews.llvm.org/D60388 > llvm-svn: 366860 llvm-svn: 366897
* Revert "FileCheck [8/12]: Define numeric var from expr"Thomas Preud'homme2019-07-241-21/+5
| | | | | | This reverts commit 1b05977538d9487aa845ee2f3bec8b89c63c4f29. llvm-svn: 366872
* FileCheck [8/12]: Define numeric var from exprThomas Preud'homme2019-07-231-5/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch is part of a patch series to add support for FileCheck numeric expressions. This specific patch lift the restriction for a numeric expression to either be a variable definition or a numeric expression to try to match. This commit allows a numeric variable to be set to the result of the evaluation of a numeric expression after it has been matched successfully. When it happens, the variable is allowed to be used on the same line since its value is known at match time. It also makes use of this possibility to reuse the parsing code to parse a command-line definition by crafting a mirror string of the -D option with the equal sign replaced by a colon sign, e.g. for option '-D#NUMVAL=10' it creates the string '-D#NUMVAL=10 (parsed as [[#NUMVAL:10]])' where the numeric expression is parsed to define NUMVAL. This result in a few tests needing updating for the location diagnostics on top of the tests for the new feature. It also enables empty numeric expression which match any number without defining a variable. This is done here rather than in commit #5 of the patch series because it requires to dissociate automatic regex insertion in RegExStr from variable definition which would make commit #5 even bigger than it already is. Copyright: - Linaro (changes up to diff 183612 of revision D55940) - GraphCore (changes in later versions of revision D55940 and in new revision created off D55940) Reviewers: jhenderson, chandlerc, jdenny, probinson, grimar, arichardson, rnk Subscribers: hiraditya, llvm-commits, probinson, dblaikie, grimar, arichardson, tra, rnk, kristina, hfinkel, rogfer01, JonChesterfield Tags: #llvm Differential Revision: https://reviews.llvm.org/D60388 llvm-svn: 366860
* [docs] Clarify where the indirect UB due to write-write races comes fromEli Friedman2019-07-231-2/+4
| | | | | | | | This is based on https://bugs.llvm.org/show_bug.cgi?id=42435#c3. Patch by Ralf Jung. llvm-svn: 366855
* [Remarks] Introduce a new format: yaml-strtabFrancis Visoiu Mistrih2019-07-231-0/+29
| | | | | | | | | This exposes better support to use a string table with a format through an actual new remark::Format, called yaml-strtab. This can now be used with -fsave-optimization-record=yaml-strtab. llvm-svn: 366849
* [IR][Verifier] Allow IntToPtrInst to be !dereferenceableRyan Taylor2019-07-231-15/+42
| | | | | | | | | | | | | | | | | Summary: Allow IntToPtrInst to carry !dereferenceable metadata tag. This is valid since !dereferenceable can be only be applied to pointer type values. Change-Id: If8a6e3c616f073d51eaff52ab74535c29ed497b4 Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64954 llvm-svn: 366826
* unbreak linksChris Lattner2019-07-1911-11/+11
| | | | llvm-svn: 366530
* replace the old kaleidoscope tutorial files with orphaned pages that forward ↵Chris Lattner2019-07-1913-5638/+47
| | | | | | to the new copy. llvm-svn: 366529
* Point to the dusted off version of the kaleidoscope tutorial.Chris Lattner2019-07-192-2/+4
| | | | llvm-svn: 366528
* [CMake] Don't set Python_ADDITIONAL_VERSIONSJonas Devlieghere2019-07-181-0/+5
| | | | | | | | | | | | | | | | | | | | | | Until recently, Python_ADDITIONAL_VERSIONS was used to limit LLVM's Python support to 2.7. Now that both LLVM and LLDB both support Python 3, there's no longer a need to put an arbitrary limit on this. However, instead of removing the variable, r365692 expanded the list, which has the (presumably unintentional) side-effect of expression preference for Python 3. Instead, as Michal proposed in the original code review, we should just not set the list at all, and let CMake pick whatever Python interpreter you have in your path. This patch removes the Python_ADDITIONAL_VERSIONS variable in llvm, clang and lld. I've also updated the docs with the default behavior and how to force a different Python version to be used. Differential revision: https://reviews.llvm.org/D64894 llvm-svn: 366447
* Bump the trunk version to 10.0.0svnHans Wennborg2019-07-182-55/+9
| | | | | | and clear the release notes. llvm-svn: 366427
* Fix typo in programmer's manual cantFile -> cantFailNathan Lanza2019-07-181-1/+1
| | | | llvm-svn: 366403
* [ORC][docs] Fix an RST error: the code-block directive needs a newline after it.Lang Hames2019-07-161-0/+1
| | | | llvm-svn: 366270
* [ORC][docs] Trim ORCv1 to ORCv2 transition section, add a how-to section.Lang Hames2019-07-161-121/+288
| | | | llvm-svn: 366269
* Revert [tools] [llvm-nm] Default to reading from stdin not a.outAlex Brachet2019-07-161-2/+3
| | | | | | This reverts r365889 (git commit 60c81354b1d3fced1bd284d334f118d2d792ab4b) llvm-svn: 366219
* [Remarks] Simplify and refactor the RemarkParser interfaceFrancis Visoiu Mistrih2019-07-161-0/+1
| | | | | | | | | | | | | | | | | | | | Before, everything was based on some kind of type erased parser implementation which container a lot of boilerplate code when multiple formats were to be supported. This simplifies it by: * the remark now owns its arguments * *always* returning an error from the implementation side * working around the way the YAML parser reports errors: catch them through callbacks and re-insert them in a proper llvm::Error * add a CParser wrapper that is used when implementing the C API to avoid cluttering the C++ API with useless state * LLVMRemarkParserGetNext now returns an object that needs to be released to avoid leaking resources * add a new API to dispose of a remark entry: LLVMRemarkEntryDispose llvm-svn: 366217
* remove a duplicate declarationSylvestre Ledru2019-07-161-3/+0
| | | | llvm-svn: 366205
* Document the LLVM_ENABLE_BINDINGS optionSylvestre Ledru2019-07-161-0/+6
| | | | llvm-svn: 366204
* ARM MTE stack sanitizer.Evgeniy Stepanov2019-07-152-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Add "memtag" sanitizer that detects and mitigates stack memory issues using armv8.5 Memory Tagging Extension. It is similar in principle to HWASan, which is a software implementation of the same idea, but there are enough differencies to warrant a new sanitizer type IMHO. It is also expected to have very different performance properties. The new sanitizer does not have a runtime library (it may grow one later, along with a "debugging" mode). Similar to SafeStack and StackProtector, the instrumentation pass (in a follow up change) will be inserted in all cases, but will only affect functions marked with the new sanitize_memtag attribute. Reviewers: pcc, hctim, vitalybuka, ostannard Subscribers: srhines, mehdi_amini, javed.absar, kristof.beyls, hiraditya, cryptoad, steven_wu, dexonsmith, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D64169 llvm-svn: 366123
* Add some release notes for 9.0 releaseMatt Arsenault2019-07-151-1/+11
| | | | llvm-svn: 366093
* [docs][llvm-nm] Fix inconsistent grammarJames Henderson2019-07-151-1/+1
| | | | llvm-svn: 366080
OpenPOWER on IntegriCloud