summaryrefslogtreecommitdiffstats
path: root/llvm/docs
Commit message (Collapse)AuthorAgeFilesLines
...
* index.rst: Remove bb-chapuni from list of IRC botsHans Wennborg2019-02-191-1/+0
| | | | llvm-svn: 354353
* index.rst: Remove Dragonegg linkHans Wennborg2019-02-191-5/+4
| | | | llvm-svn: 354352
* [llvm-exegesis] [NFC] Fixing typo.Guillaume Chatelet2019-02-181-1/+1
| | | | | | | | | | | | Reviewers: courbet, gchatelet Reviewed By: courbet, gchatelet Subscribers: tschuett, llvm-commits Differential Revision: https://reviews.llvm.org/D54895 llvm-svn: 354250
* Fixed code snippet in Kaleidoscope tutorial to reflect final full code listingWilfred Hughes2019-02-161-1/+1
| | | | | | | | Patch by Frank He. Differential Revision: https://reviews.llvm.org/D52166 llvm-svn: 354205
* Fix typo in docsDmitri Gribenko2019-02-161-1/+1
| | | | | | | | Patch by Alex Yursha. Differential Revision: https://reviews.llvm.org/D45903 llvm-svn: 354203
* [docs] Document LLVM_ENABLE_IDEShoaib Meenai2019-02-151-0/+9
| | | | | | | | | Use some of the wording and the motivating example from r344555. The lack of documentation was pointed out by Roman Lebedev. Differential Revision: https://reviews.llvm.org/D58286 llvm-svn: 354167
* Stop enabling clang-tools-extra automatically when clang is in ↵Nico Weber2019-02-141-2/+2
| | | | | | | | | | | | | | LLVM_ENABLE_PROJECTS If you want to build clang-tools-extra with monorepo, just add it to LLVM_ENABLE_PROJECTS like with other projects. See also "Separating clang-tools-extra from clang in LLVM_ENABLE_PROJECTS" on cfe-dev. Differential Revision: https://reviews.llvm.org/D58157 llvm-svn: 354057
* LibFuzzer.rst: double backticksHans Wennborg2019-02-121-3/+3
| | | | llvm-svn: 353809
* Add recipes for migrating downstream branches of git mirrorsDavid Greene2019-02-111-0/+534
| | | | | | | | | | Add some common recipes for downstream users developing on top of the existing git mirrors. These instructions show how to migrate local branches to the monorepo. Differential Revision: https://reviews.llvm.org/D56550 llvm-svn: 353713
* [Docs] Use code-block:: text for part of the callbr documentation to attempt ↵Craig Topper2019-02-081-1/+1
| | | | | | to make the bot happy. llvm-svn: 353567
* Implementation of asm-goto support in LLVMCraig Topper2019-02-081-0/+80
| | | | | | | | | | | | | | | | | | | | | | | | | This patch accompanies the RFC posted here: http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html This patch adds a new CallBr IR instruction to support asm-goto inline assembly like gcc as used by the linux kernel. This instruction is both a call instruction and a terminator instruction with multiple successors. Only inline assembly usage is supported today. This also adds a new INLINEASM_BR opcode to SelectionDAG and MachineIR to represent an INLINEASM block that is also considered a terminator instruction. There will likely be more bug fixes and optimizations to follow this, but we felt it had reached a point where we would like to switch to an incremental development model. Patch by Craig Topper, Alexander Ivchenko, Mikhail Dvoretckii Differential Revision: https://reviews.llvm.org/D53765 llvm-svn: 353563
* Document libFuzzer on Windows.Jonathan Metzman2019-02-081-2/+12
| | | | | | | | | | | | | | | | Summary: Document that libFuzzer supports Windows, how to get it, and its limitations. Reviewers: kcc, morehouse, rnk, metzman Reviewed By: kcc, rnk, metzman Subscribers: hans, rnk Differential Revision: https://reviews.llvm.org/D57597 llvm-svn: 353551
* [Cmake] Add an option to build LLVM using the experimental new pass managerRong Xu2019-02-081-0/+3
| | | | | | | | Add LLVM_USE_NEWPM to build LLVM using the experimental new pass manager. Differential Revision: http://reviews.llvm.org/D57068 llvm-svn: 353550
* [AMDGPU][MC][CODEOBJECT] Added predefined symbols to access GPU minor and ↵Dmitry Preobrazhensky2019-02-081-2/+18
| | | | | | | | | | | | | | stepping numbers Added the following Code Object v3 symbols: .amdgcn.gfx_generation_minor .amdgcn.gfx_generation_stepping Reviewers: artem.tamazov, kzhuravl Differential Revision: https://reviews.llvm.org/D57826 llvm-svn: 353515
* Bump minimum toolchain versionJF Bastien2019-02-072-17/+33
| | | | | | | | | | | | | | | Summary: The RFC on moving past C++11 got good traction: http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html This patch therefore bumps the toolchain versions according to our policy: llvm.org/docs/DeveloperPolicy.html#toolchain Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane Differential Revision: https://reviews.llvm.org/D57264 llvm-svn: 353374
* [ADT] Add a fallible_iterator wrapper.Lang Hames2019-02-051-11/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A fallible iterator is one whose increment or decrement operations may fail. This would usually be supported by replacing the ++ and -- operators with methods that return error: class MyFallibleIterator { public: // ... Error inc(); Errro dec(); // ... }; The downside of this style is that it no longer conforms to the C++ iterator concept, and can not make use of standard algorithms and features such as range-based for loops. The fallible_iterator wrapper takes an iterator written in the style above and adapts it to (mostly) conform with the C++ iterator concept. It does this by providing standard ++ and -- operator implementations, returning any errors generated via a side channel (an Error reference passed into the wrapper at construction time), and immediately jumping the iterator to a known 'end' value upon error. It also marks the Error as checked any time an iterator is compared with a known end value and found to be inequal, allowing early exit from loops without redundant error checking*. Usage looks like: MyFallibleIterator I = ..., E = ...; Error Err = Error::success(); for (auto &Elem : make_fallible_range(I, E, Err)) { // Loop body is only entered when safe. // Early exits from loop body permitted without checking Err. if (SomeCondition) return; } if (Err) // Handle error. * Since failure causes a fallible iterator to jump to end, testing that a fallible iterator is not an end value implicitly verifies that the error is a success value, and so is equivalent to an error check. Reviewers: dblaikie, rupprecht Subscribers: mgorny, dexonsmith, kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57618 llvm-svn: 353237
* [Intrinsic] Unsigned Fixed Point Multiplication IntrinsicLeonard Chan2019-02-041-2/+62
| | | | | | | | | | | | | Add an intrinsic that takes 2 unsigned integers with the scale of them provided as the third argument and performs fixed point multiplication on them. This is a part of implementing fixed point arithmetic in clang where some of the more complex operations will be implemented as intrinsics. Differential Revision: https://reviews.llvm.org/D55625 llvm-svn: 353059
* [llvm-exegesis] Don't default to running&dumping all analyses to '-'Roman Lebedev2019-02-041-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Up until the point i have looked in the source, i didn't even understood that i can disable 'cluster' output. I have always silenced it via ` &> /dev/null`. (And hoped it wasn't contributing much of the run time.) While i expect that it has it's use-cases i never once needed it so far. If i forget to silence it, console is completely flooded with that output. How about not expecting users to opt-out of analyses, but to explicitly specify the analyses that should be performed? Reviewers: courbet, gchatelet Reviewed By: courbet Subscribers: tschuett, RKSimon, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57648 llvm-svn: 353021
* [docs] Recommend assertions when testing.Davide Italiano2019-02-031-1/+1
| | | | | | Pointed out by Shoaib Meenai. llvm-svn: 353008
* Revert "Bump minimum toolchain version"JF Bastien2019-02-022-33/+17
| | | | | | | | | | | Reverting D57264 again, it looks like we're down to two bots that need fixing: polly-amd64-linux polly-arm-linux They both have old versions of libstdc++ and recent clang. llvm-svn: 352954
* Bump minimum toolchain versionJF Bastien2019-02-022-17/+33
| | | | | | | | | | | | | | | Summary: The RFC on moving past C++11 got good traction: http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html This patch therefore bumps the toolchain versions according to our policy: llvm.org/docs/DeveloperPolicy.html#toolchain Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane Differential Revision: https://reviews.llvm.org/D57264 llvm-svn: 352951
* Hopefully fix a couple more sphinx doc errors.James Y Knight2019-02-011-2/+10
| | | | | | | These seem to only appear on the buildbot runner, and it looks like we tried to suppress them, but it's not working. Not sure why. llvm-svn: 352903
* Fix some sphinx doc errors.James Y Knight2019-02-011-0/+2
| | | | llvm-svn: 352887
* [doc]Update String Error documentation in Programmer ManualJames Henderson2019-02-011-4/+14
| | | | | | | | | | | | | A while back, createStringError was added to provide easier construction of StringError instances, especially with formatting options. Prior to this patch, that the documentation only mentions the standard method of using it. Since createStringError is slightly shorter to type, and also provides the formatting options, this patch updates the Programmer's Manual to use the new function in its examples, and to mention the printf formatting options. It also fixes a small typo in one of the examples and removes the unnecessary make_error_code call. llvm-svn: 352846
* Revert "Bump minimum toolchain version"JF Bastien2019-02-012-33/+17
| | | | | | Looks like we still have a few bots that are sad. Let try to get them fixed! llvm-svn: 352835
* Bump minimum toolchain versionJF Bastien2019-02-012-17/+33
| | | | | | | | | | | | | | | Summary: The RFC on moving past C++11 got good traction: http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html This patch therefore bumps the toolchain versions according to our policy: llvm.org/docs/DeveloperPolicy.html#toolchain Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane Differential Revision: https://reviews.llvm.org/D57264 llvm-svn: 352834
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-02-011-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc doesn't choke on it, hopefully. Original Message: The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352827
* Revert "Bump minimum toolchain version"JF Bastien2019-01-312-33/+17
| | | | | | | | A handful of bots are still breaking, either because I missed them in my audit, they were offline, or something else. I'm contacting their authors, but I'll revert for now and re-commit later. llvm-svn: 352814
* DeveloperPolicy: update toolchain with sample RFC / patchJF Bastien2019-01-311-0/+3
| | | | | | As was suggested when the policy originally went in. llvm-svn: 352812
* Bump minimum toolchain versionJF Bastien2019-01-312-17/+33
| | | | | | | | | | | | | | | Summary: The RFC on moving past C++11 got good traction: http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html This patch therefore bumps the toolchain versions according to our policy: llvm.org/docs/DeveloperPolicy.html#toolchain Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane Differential Revision: https://reviews.llvm.org/D57264 llvm-svn: 352811
* Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."James Y Knight2019-01-311-11/+5
| | | | | | | | | This reverts commit f47d6b38c7a61d50db4566b02719de05492dcef1 (r352791). Seems to run into compilation failures with GCC (but not clang, where I tested it). Reverting while I investigate. llvm-svn: 352800
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-01-311-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352791
* [libFuzzer] update docsKostya Serebryany2019-01-311-5/+6
| | | | llvm-svn: 352715
* Add a 'dynamic' parameter to the objectsize intrinsicErik Pilkington2019-01-301-19/+19
| | | | | | | | | | | | | | This is meant to be used with clang's __builtin_dynamic_object_size. When 'true' is passed to this parameter, the intrinsic has the potential to be folded into instructions that will be evaluated at run time. When 'false', the objectsize intrinsic behaviour is unchanged. rdar://32212419 Differential revision: https://reviews.llvm.org/D56761 llvm-svn: 352664
* [llvm-exegesis] Add throughput mode.Clement Courbet2019-01-301-8/+10
| | | | | | | | | | | | | | | | Summary: This just uses the latency benchmark runner on the parallel uops snippet generator. Fixes PR37698. Reviewers: gchatelet Subscribers: tschuett, RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D57000 llvm-svn: 352632
* [docs] Prevent O0 optnone for opt inputShoaib Meenai2019-01-291-2/+2
| | | | | | | | | | If we just compile with -O0, clang will add optnone attributes everywhere, so opt won't actually be able to perform any passes. Instruct clang to not emit the optnone so opt can do its thing. Differential Revision: https://reviews.llvm.org/D56950 llvm-svn: 352550
* Adjust documentation for git migration.James Y Knight2019-01-295-17/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes most references to the paths: llvm.org/svn/ llvm.org/git/ llvm.org/viewvc/ github.com/llvm-mirror/ github.com/llvm-project/ reviews.llvm.org/diffusion/ to instead point to https://github.com/llvm/llvm-project. This is *not* a trivial substitution, because additionally, all the checkout instructions had to be migrated to instruct users on how to use the monorepo layout, setting LLVM_ENABLE_PROJECTS instead of checking out various projects into various subdirectories. I've attempted to not change any scripts here, only documentation. The scripts will have to be addressed separately. Additionally, I've deleted one document which appeared to be outdated and unneeded: lldb/docs/building-with-debug-llvm.txt Differential Revision: https://reviews.llvm.org/D57330 llvm-svn: 352514
* [llvm-symbolizer][doc] Tweak wording of --adjust-vma switch descriptionJames Henderson2019-01-291-2/+1
| | | | | | The address isn't dynamically relocated. The object is. llvm-svn: 352477
* [docs] Fix a couple spelling errors.Eli Friedman2019-01-282-2/+2
| | | | llvm-svn: 352439
* [LangRef] Mention vector support for bitreverse/bswap intrinsics (PR38012)Simon Pilgrim2019-01-281-8/+12
| | | | | | Differential Revision: https://reviews.llvm.org/D57309 llvm-svn: 352386
* [TblGen][NFC] Fix documentation formattingJaved Absar2019-01-251-7/+3
| | | | llvm-svn: 352212
* [llvm-symbolizer] Add switch to adjust addresses by fixed offsetJames Henderson2019-01-251-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | If a stack trace or similar has a list of addresses from an executable or DSO loaded at a variable address (e.g. due to ASLR), the addresses will not directly correspond to the addresses stored in the object file. If a user wishes to use llvm-symbolizer, they have to subtract the load address from every address. This is somewhat inconvenient, especially as the output of --print-address will result in the adjusted address being listed, rather than the address coming from the stack trace, making it harder to map results between the two. This change adds a new switch to llvm-symbolizer --adjust-vma which takes an offset, which is then used to automatically do this calculation. The printed address remains the input address (allowing for easy mapping), whilst the specified offset is applied to the addresses when performing the lookup. The switch is conceptually similar to llvm-objdump's new switch of the same name (see D57051), which in turn mirrors a GNU switch. There is no equivalent switch in addr2line. Reviewed by: grimar Differential Revision: https://reviews.llvm.org/D57151 llvm-svn: 352195
* [TblGen] Extend !if semantics through new feature !condJaved Absar2019-01-252-1/+23
| | | | | | | | | | | | | | | | | This patch extends TableGen language with !cond operator. Instead of embedding !if inside !if which can get cumbersome, one can now use !cond. Below is an example to convert an integer 'x' into a string: !cond(!lt(x,0) : "Negative", !eq(x,0) : "Zero", !eq(x,1) : "One, 1 : "MoreThanOne") Reviewed By: hfinkel, simon_tatham, greened Differential Revision: https://reviews.llvm.org/D55758 llvm-svn: 352185
* Revert "[Sanitizers] UBSan unreachable incompatible with ASan in the ↵Julian Lettner2019-01-241-4/+0
| | | | | | | | presence of `noreturn` calls" This reverts commit cea84ab93aeb079a358ab1c8aeba6d9140ef8b47. llvm-svn: 352069
* [Docs] Add information about unit tests to the testing guideMichael Platings2019-01-241-10/+25
| | | | | | Differential Revision: https://reviews.llvm.org/D57088 llvm-svn: 352052
* [docs] Remove extra character from git URL in Getting Started guide.Douglas Yung2019-01-241-1/+1
| | | | llvm-svn: 352005
* [Sanitizers] UBSan unreachable incompatible with ASan in the presence of ↵Julian Lettner2019-01-241-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `noreturn` calls Summary: UBSan wants to detect when unreachable code is actually reached, so it adds instrumentation before every `unreachable` instruction. However, the optimizer will remove code after calls to functions marked with `noreturn`. To avoid this UBSan removes `noreturn` from both the call instruction as well as from the function itself. Unfortunately, ASan relies on this annotation to unpoison the stack by inserting calls to `_asan_handle_no_return` before `noreturn` functions. This is important for functions that do not return but access the the stack memory, e.g., unwinder functions *like* `longjmp` (`longjmp` itself is actually "double-proofed" via its interceptor). The result is that when ASan and UBSan are combined, the `noreturn` attributes are missing and ASan cannot unpoison the stack, so it has false positives when stack unwinding is used. Changes: # UBSan now adds the `expect_noreturn` attribute whenever it removes the `noreturn` attribute from a function # ASan additionally checks for the presence of this attribute Generated code: ``` call void @__asan_handle_no_return // Additionally inserted to avoid false positives call void @longjmp call void @__asan_handle_no_return call void @__ubsan_handle_builtin_unreachable unreachable ``` The second call to `__asan_handle_no_return` is redundant. This will be cleaned up in a follow-up patch. rdar://problem/40723397 Reviewers: delcypher, eugenis Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D56624 llvm-svn: 352003
* [llvm-symbolizer] Add support for -i and -inlines as aliases for -inliningDouglas Yung2019-01-241-1/+1
| | | | | | | | | | | | | | This change adds two options, -i and -inlines as aliases for the -inlining option to llvm-symbolizer to improve compatibility with the GNU addr2line utility which accepts these options. It also modifies existing tests that use -inlining to exercise these new aliases as well. This fixes PR40073. Reviewed by: jhenderson, Quolyk, ruiu Differential Revision: https://reviews.llvm.org/D57083 llvm-svn: 351999
* [llvm-symbolizer] Improve compatibility of --functions with GNU addr2lineJames Henderson2019-01-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This fixes https://bugs.llvm.org/show_bug.cgi?id=40072. GNU addr2line's --functions switch is off by default, has a short alias of -f, and does not take an argument. This patch changes llvm-symbolizer to allow the second and third point (changing the default behaviour may have negative impacts on users). If the option is missing a value, it now treats it as "linkage". This change does cause one previously valid command-line to behave differently. Before --functions <value> was accepted, but now only --functions=<value> is allowed (as well as --functions). The old behaviour will result in the value being treated as a positional argument. The previous testing for --functions=short has been pulled out into a new test that also tests the other accepted values and option formats. Reviewed by: ruiu Differential Revision: https://reviews.llvm.org/D57049 llvm-svn: 351968
* [Docs] Add a note clarifying how to get good test performances.Davide Italiano2019-01-221-0/+7
| | | | | | Differential Revision: https://reviews.llvm.org/D56337 llvm-svn: 351885
OpenPOWER on IntegriCloud