summaryrefslogtreecommitdiffstats
path: root/llvm/docs
Commit message (Collapse)AuthorAgeFilesLines
* MC: Introduce the ABS8 symbol modifier.Peter Collingbourne2017-01-311-0/+22
| | | | | | | | | | | @ABS8 can be applied to symbols which appear as immediate operands to instructions that have a 8-bit immediate form for that operand. It causes the assembler to use the 8-bit form and an 8-bit relocation (e.g. R_386_8 or R_X86_64_8) for the symbol. Differential Revision: https://reviews.llvm.org/D28688 llvm-svn: 293667
* [LanRef] Fix typo in getelementptr example.Alexey Bader2017-01-301-1/+1
| | | | | | | | | | | | | | Summary: Change B type from double to pointer to double. Reviewers: delena, sanjoy Reviewed By: sanjoy Subscribers: sanjoy, llvm-commits Differential Revision: https://reviews.llvm.org/D29009 llvm-svn: 293467
* Use print() instead of dump() in codeMatthias Braun2017-01-281-2/+4
| | | | | | | The dump() functions are meant to be used in a debugger, code should typically use something like print(errs()); llvm-svn: 293365
* Update NVVMReflect usage doc to new idiom for adding target-specific early ↵Justin Lebar2017-01-271-5/+2
| | | | | | passes. llvm-svn: 293327
* [LangRef] Make @llvm.sqrt(x) return undef, rather than have UB, for negative x.Justin Lebar2017-01-271-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Some frontends emit a speculate-and-select idiom for sqrt, wherein they compute sqrt(x), check if x is negative, and select NaN if it is: %cmp = fcmp olt double %a, -0.000000e+00 %sqrt = call double @llvm.sqrt.f64(double %a) %ret = select i1 %cmp, double 0x7FF8000000000000, double %sqrt This is technically UB as the LangRef is written today if %a is ever less than -0. But emitting code that's compliant with the current definition of sqrt would require a branch, which would then prevent us from matching this idiom in SelectionDAG (which we do today -- ISD::FSQRT has defined behavior on negative inputs), because SelectionDAG looks at one BB at a time. Nothing in LLVM takes advantage of this undefined behavior, as far as we can tell, and the fact that llvm.sqrt has UB dates from its initial addition to the LangRef. Reviewers: arsenm, mehdi_amini, hfinkel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D28797 llvm-svn: 293242
* Add intrinsics for constrained floating point operationsAndrew Kaylor2017-01-261-0/+271
| | | | | | | | | | | | | | This commit introduces a set of experimental intrinsics intended to prevent optimizations that make assumptions about the rounding mode and floating point exception behavior. These intrinsics will later be extended to specify flush-to-zero behavior. More work is also required to model instruction dependencies in machine code and to generate these instructions from clang (when required by pragmas and/or command line options that are not currently supported). Differential Revision: https://reviews.llvm.org/D27028 llvm-svn: 293226
* [Doc][LangRef] Fix typo-ish error in description of Masked GatherZvi Rackover2017-01-261-1/+1
| | | | | | | | | | | | | | Summary: Fix the example of equivalent expansion for when mask is all ones. Reviewers: delena Reviewed By: delena Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29179 llvm-svn: 293206
* LangRef: Document the allowed metadata dropping transforms.Peter Collingbourne2017-01-251-3/+16
| | | | | | | | | Document the current practice regarding dropping metadata on modules, functions and global variables. Differential Revision: https://reviews.llvm.org/D29110 llvm-svn: 293101
* Reinstate "r292904 - [lit] Allow boolean expressions in REQUIRES and XFAILGreg Parker2017-01-251-28/+36
| | | | | | | | and UNSUPPORTED" This reverts the revert in r292942. llvm-svn: 293007
* Revert "r292904 - [lit] Allow boolean expressions in REQUIRES and XFAILAlex Lorenz2017-01-241-36/+28
| | | | | | | | | | | and UNSUPPORTED" After r292904 llvm-lit fails to emit the test results in the XML format for Apple's internal buildbots. rdar://30164800 llvm-svn: 292942
* [lit] Allow boolean expressions in REQUIRES and XFAIL and UNSUPPORTEDGreg Parker2017-01-241-28/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | A `lit` condition line is now a comma-separated list of boolean expressions. Comma-separated expressions act as if each expression were on its own condition line: For REQUIRES, if every expression is true then the test will run. For UNSUPPORTED, if every expression is false then the test will run. For XFAIL, if every expression is false then the test is expected to succeed. As a special case "XFAIL: *" expects the test to fail. Examples: # Test is expected fail on 64-bit Apple simulators and pass everywhere else XFAIL: x86_64 && apple && !macosx # Test is unsupported on Windows and on non-Ubuntu Linux # and supported everywhere else UNSUPPORTED: linux && !ubuntu, system-windows Syntax: * '&&', '||', '!', '(', ')'. 'true' is true. 'false' is false. * Each test feature is a true identifier. * Substrings of the target triple are true identifiers for UNSUPPORTED and XFAIL, but not for REQUIRES. (This matches the current behavior.) * All other identifiers are false. * Identifiers are [-+=._a-zA-Z0-9]+ Differential Revision: https://reviews.llvm.org/D18185 llvm-svn: 292904
* Revert "[lit] Allow boolean expressions in REQUIRES and XFAIL and UNSUPPORTED"Greg Parker2017-01-241-36/+28
| | | | | | This change needs to be better-coordinated with libc++. llvm-svn: 292900
* [lit] Allow boolean expressions in REQUIRES and XFAIL and UNSUPPORTEDGreg Parker2017-01-241-28/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | A `lit` condition line is now a comma-separated list of boolean expressions. Comma-separated expressions act as if each expression were on its own condition line: For REQUIRES, if every expression is true then the test will run. For UNSUPPORTED, if every expression is false then the test will run. For XFAIL, if every expression is false then the test is expected to succeed. As a special case "XFAIL: *" expects the test to fail. Examples: # Test is expected fail on 64-bit Apple simulators and pass everywhere else XFAIL: x86_64 && apple && !macosx # Test is unsupported on Windows and on non-Ubuntu Linux # and supported everywhere else UNSUPPORTED: linux && !ubuntu, system-windows Syntax: * '&&', '||', '!', '(', ')'. 'true' is true. 'false' is false. * Each test feature is a true identifier. * Substrings of the target triple are true identifiers for UNSUPPORTED and XFAIL, but not for REQUIRES. (This matches the current behavior.) * All other identifiers are false. * Identifiers are [-+=._a-zA-Z0-9]+ Differential Revision: https://reviews.llvm.org/D18185 llvm-svn: 292896
* [AArch64][GlobalISel] Legalize narrow scalar ops again.Ahmed Bougacha2017-01-231-35/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since r279760, we've been marking as legal operations on narrow integer types that have wider legal equivalents (for instance, G_ADD s8). Compared to legalizing these operations, this reduced the amount of extends/truncates required, but was always a weird legalization decision made at selection time. So far, we haven't been able to formalize it in a way that permits the selector generated from SelectionDAG patterns to be sufficient. Using a wide instruction (say, s64), when a narrower instruction exists (s32) would introduce register class incompatibilities (when one narrow generic instruction is selected to the wider variant, but another is selected to the narrower variant). It's also impractical to limit which narrow operations are matched for which instruction, as restricting "narrow selection" to ranges of types clashes with potentially incompatible instruction predicates. Concerns were also raised regarding MIPS64's sign-extended register assumptions, as well as wrapping behavior. See discussions in https://reviews.llvm.org/D26878. Instead, legalize the operations. Should we ever revert to selecting these narrow operations, we should try to represent this more accurately: for instance, by separating a "concrete" type on operations, and an "underlying" type on vregs, we could move the "this narrow-looking op is really legal" decision to the legalizer, and let the selector use the "underlying" vreg type only, which would be guaranteed to map to a register class. In any case, we eventually should mitigate: - the performance impact by selecting no-op extract/truncates to COPYs (which we currently do), and the COPYs to register reuses (which we don't do yet). - the compile-time impact by optimizing away extract/truncate sequences in the legalizer. llvm-svn: 292827
* [docs] Point to upstream Sphinx install instructions.Sean Silva2017-01-221-0/+2
| | | | llvm-svn: 292752
* docs: Document that !absolute_symbol { all-ones, all-ones } means the full set.Peter Collingbourne2017-01-201-2/+5
| | | | llvm-svn: 292657
* [docs] Tell Doxygen to expand LLVM_ALIGNAS to nothingMalcolm Parsons2017-01-191-3/+3
| | | | | | | | | | | | | | | | | Summary: Docs for clang::Decl and clang::TemplateSpecializationType have not been generated since LLVM_ALIGNAS was added to them. Tell Doxygen to expand LLVM_ALIGNAS to nothing as described at https://www.stack.nl/~dimitri/doxygen/manual/preprocessing.html Reviewers: aaron.ballman, klimek, alexfh Subscribers: ioeric, cfe-commits Differential Revision: https://reviews.llvm.org/D28850 llvm-svn: 292483
* [lit] Support sharding testsuites, for parallel execution.Graydon Hoare2017-01-181-0/+17
| | | | | | | | | | | | | | | | | | | | | | | Summary: This change equips lit.py with two new options, --num-shards=M and --run-shard=N (set by default from env vars LIT_NUM_SHARDS and LIT_RUN_SHARD). The options must be used together, and N must be in 1..M. Together these options effect only test selection: they partition the testsuite into M equal-sized "shards", then select only the Nth shard. They can be used in a cluster of test machines to achieve a very crude (static) form of parallelism, with minimal configuration work. Reviewers: modocache, ddunbar Reviewed By: ddunbar Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28789 llvm-svn: 292417
* [libFuzzer] better link for trophiesKostya Serebryany2017-01-181-1/+1
| | | | llvm-svn: 292318
* Fix GettingStarted doc so that the example build command for cmake ↵Mehdi Amini2017-01-171-1/+1
| | | | | | | | | LLVM_ENABLE_PROJECTS works on linux I tested the previous one on macOS, however building libc++ on Linux requires libcxxabi as well. llvm-svn: 292290
* Silence some Sphinx diagnostics in an attempt to get the documentation ↵Aaron Ballman2017-01-173-2/+3
| | | | | | builder back to green (http://lab.llvm.org:8011/builders/llvm-sphinx-docs/builds/1895). llvm-svn: 292271
* [NVPTX] Add blank line to NVPTXUsage.rst to appease the Sphinx.Justin Lebar2017-01-161-0/+1
| | | | | | | | | | | Fixes: Warning, treated as error: /home/buildbot/llvm-build-dir/llvm-sphinx-docs/llvm/src/docs/NVPTXUsage.rst:333: ERROR: Error in "code-block" directive: maximum 1 argument(s) allowed, 17 supplied. llvm-svn: 292148
* [NVPTX] Let there be One True Way to set NVVMReflect params.Justin Lebar2017-01-151-28/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously there were three ways to inform the NVVMReflect pass whether you wanted to flush denormals to zero: * An LLVM command-line option * Parameters to the NVVMReflect constructor * Metadata on the module itself. This change removes the first two, leaving only the third. The motivation for this change, aside from simplifying things, is that we want LLVM to be aware of whether it's operating in FTZ mode, so other passes can use this information. Ideally we'd have a target-generic piece of metadata on the module. This change moves us in that direction. Reviewers: tra Subscribers: jholewinski, llvm-commits Differential Revision: https://reviews.llvm.org/D28700 llvm-svn: 292068
* Add a LLVM_USE_LINKER that defines the linker to use when building LLVMMehdi Amini2017-01-151-0/+12
| | | | | | | | | | | | | | | Summary: This string parameter is passed to -fuse-ld when linking. It can be an absolute path to your custom linker, otherwise clang will look for `ld.{name}`. Reviewers: davide, tejohnson, pcc Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D28738 llvm-svn: 292047
* fix some typos in the docSylvestre Ledru2017-01-148-10/+10
| | | | llvm-svn: 292014
* Add a description how to checkout the LLD repository.Rui Ueyama2017-01-131-0/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D28687 llvm-svn: 291948
* Clear the release notes for 5.0.0Hans Wennborg2017-01-121-28/+8
| | | | llvm-svn: 291836
* Bump trunk version to 5.0.0svnHans Wennborg2017-01-121-3/+3
| | | | llvm-svn: 291815
* LangRef: Note that calls also support fast math flagsMatt Arsenault2017-01-101-2/+3
| | | | | | | | This is already documented on the call instruction, but not in the list of supported instructions in the fast math flag section. llvm-svn: 291578
* [Docs] Update docs to indicate that CUDA compilation is supported on Windows.Justin Lebar2017-01-051-2/+2
| | | | | | | | Subscribers: cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D28326 llvm-svn: 291139
* [doc] Fix minor grammatical error in Phabricator.rstAnmol P. Paralkar2017-01-051-1/+1
| | | | | | | | | | | | Summary: Test commit, fix minor grammatical error in Phabricator.rst Reviewers: delcypher Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28214 llvm-svn: 291101
* [cmake] Add LLVM_ENABLE_DIA_SDK option, and expose it in LLVMConfigMichal Gorny2017-01-021-0/+4
| | | | | | | | | | | | | | | Add an explicit LLVM_ENABLE_DIA_SDK option to control building support for DIA SDK-based debugging. Control its value to match whether DIA SDK support was found and expose it in LLVMConfig (alike LLVM_ENABLE_ZLIB). Its value is needed for LLDB to determine whether to run tests requiring DIA support. Currently it is obtained from llvm/Config/config.h; however, this file is not available for standalone builds. Following this change, LLDB will be modified to use the value from LLVMConfig. Differential Revision: https://reviews.llvm.org/D26255 llvm-svn: 290818
* Reapply "[CodeGen] Fix invalid DWARF info on Win64"Keno Fischer2017-01-021-1/+1
| | | | | | | This reapplies rL289013 (reverted in rL289014) with the fixes identified in D21731. Should hopefully pass the buildbots this time. llvm-svn: 290809
* [doc] Clarify steps for contributors without commit access.Florian Hahn2016-12-301-2/+6
| | | | | | | | | | | | Summary: Update the Phabricator docs to clarify how changes are merged for contributors without commit access. Reviewers: delcypher, aaron.ballman Subscribers: aaron.ballman, anmol, llvm-commits Differential Revision: https://reviews.llvm.org/D28184 llvm-svn: 290767
* [MemDep] Handle gep with zeros for invariant.groupPiotr Padlewski2016-12-301-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: gep 0, 0 is equivalent to bitcast. LLVM canonicalizes it to getelementptr because it make SROA can then handle it. Simple case like void g(A &a) { z(a); if (glob) a.foo(); } void testG() { A a; g(a); } was not devirtualized with -fstrict-vtable-pointers because luck of handling for gep 0 in Memory Dependence Analysis Reviewers: dberlin, nlewycky, chandlerc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28126 llvm-svn: 290763
* Fix documentation generator warnings after rL290708.Igor Laevsky2016-12-291-3/+3
| | | | llvm-svn: 290709
* Introduce element-wise atomic memcpy intrinsicIgor Laevsky2016-12-291-0/+76
| | | | | | | | | | This change adds a new intrinsic which is intended to provide memcpy functionality with additional atomicity guarantees. Please refer to the review thread or language reference for further details. Differential Revision: https://reviews.llvm.org/D27133 llvm-svn: 290708
* [doc] Add mention of the difference in optimization level between Release ↵Mehdi Amini2016-12-261-0/+2
| | | | | | | | and RelWithDebInfo in Cmake.rst This is surprising to many people. llvm-svn: 290556
* [DebugInfo] Added support for Checksum debug info feature.Amjad Aboud2016-12-251-1/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D27642 llvm-svn: 290514
* Test commit.Bryant Wong2016-12-241-1/+0
| | | | llvm-svn: 290501
* Fix missing '>' in docs (hopefully fixes bot error... )David Blaikie2016-12-201-1/+1
| | | | llvm-svn: 290187
* Add some brief documentation about GDB pretty printersDavid Blaikie2016-12-201-0/+16
| | | | llvm-svn: 290186
* Revert @llvm.assume with operator bundles (r289755-r289757)Daniel Jasper2016-12-191-9/+0
| | | | | | | This creates non-linear behavior in the inliner (see more details in r289755's commit thread). llvm-svn: 290086
* Fix some remaining documentation references to MSVC 2013Reid Kleckner2016-12-152-4/+3
| | | | | | | | MSVC 2015 has been the minimum supported version of VS since October. Differential Revision: https://reviews.llvm.org/D25710 llvm-svn: 289854
* [libFuzzer] doc updateKostya Serebryany2016-12-151-3/+0
| | | | llvm-svn: 289849
* Simplify format member detection in FormatVariadicPavel Labath2016-12-151-9/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This replaces the format member search, which was quite complicated, with a more direct approach to detecting whether a class should be formatted using the format-member method. Instead we use a special type llvm::format_adapter, which every adapter must inherit from. Then the search can be simply implemented with the is_base_of type trait. Aside from the simplification, I like this way more because it makes it more explicit that you are supposed to use this type only for adapter-like formattings, and the other approach (format_provider overloads) should be used as a default (a mistake I made when first trying to use this library). The only slight change in behaviour here is that now choose the format-adapter branch even if the format member invocation will fail to compile (e.g. because it is a non-const member function and we are passing a const adapter), whereas previously we would have gone on to search for format_providers for the type. However, I think that is actually a good thing, as it probably means the programmer did something wrong. Reviewers: zturner, inglorion Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D27679 llvm-svn: 289795
* Make processing @llvm.assume more efficient by using operand bundlesHal Finkel2016-12-151-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | There was an efficiency problem with how we processed @llvm.assume in ValueTracking (and other places). The AssumptionCache tracked all of the assumptions in a given function. In order to find assumptions relevant to computing known bits, etc. we searched every assumption in the function. For ValueTracking, that means that we did O(#assumes * #values) work in InstCombine and other passes (with a constant factor that can be quite large because we'd repeat this search at every level of recursion of the analysis). Several of us discussed this situation at the last developers' meeting, and this implements the discussed solution: Make the values that an assume might affect operands of the assume itself. To avoid exposing this detail to frontends and passes that need not worry about it, I've used the new operand-bundle feature to add these extra call "operands" in a way that does not affect the intrinsic's signature. I think this solution is relatively clean. InstCombine adds these extra operands based on what ValueTracking, LVI, etc. will need and then those passes need only search the users of the values under consideration. This should fix the computational-complexity problem. At this point, no passes depend on the AssumptionCache, and so I'll remove that as a follow-up change. Differential Revision: https://reviews.llvm.org/D27259 llvm-svn: 289755
* [libFuzzer] document one more desired feature of a fuzz targetKostya Serebryany2016-12-141-0/+1
| | | | llvm-svn: 289622
* IR, X86: Understand !absolute_symbol metadata on global variables.Peter Collingbourne2016-12-081-0/+19
| | | | | | | | | | | | | | | | | Summary: Attaching !absolute_symbol to a global variable does two things: 1) Marks it as an absolute symbol reference. 2) Specifies the value range of that symbol's address. Teach the X86 backend to allow absolute symbols to appear in place of immediates by extending the relocImm and mov64imm32 matchers. Start using relocImm in more places where it is legal. As previously proposed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2016-October/105800.html Differential Revision: https://reviews.llvm.org/D25878 llvm-svn: 289087
* Revert "[CodeGen] Fix invalid DWARF info on Win64"Keno Fischer2016-12-081-1/+1
| | | | | | Appears to break on build bots. Reverting pending investigation. llvm-svn: 289014
OpenPOWER on IntegriCloud