summaryrefslogtreecommitdiffstats
path: root/llvm/docs/LangRef.rst
Commit message (Collapse)AuthorAgeFilesLines
* 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
* [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
* [DebugInfo] Added support for Checksum debug info feature.Amjad Aboud2016-12-251-1/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D27642 llvm-svn: 290514
* 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
* 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
* 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
* Fix doc of `llvm.bitreverse.iN`Yichao Yu2016-11-231-1/+1
| | | | | | | | | | | | | | | Summary: The return type is `iN` rather than always `i16` Seems to be a typo in https://reviews.llvm.org/rL252878 . Reviewers: jmolloy Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D27047 llvm-svn: 287769
* [LangRef] Drop misleading anecdoteSanjoy Das2016-11-131-3/+1
| | | | | | | | | | | `shl nsw i8 1, i8 8` is poison, but `mul i8 1, i8 128` is not. This was discussed previously here: http://lists.llvm.org/pipermail/llvm-dev/2015-April/084195.html. From the discussion, it was not clear which semantics we want for `shl`, but for now at least make the language reference more accurate. llvm-svn: 286785
* IR: Introduce inrange attribute on getelementptr indices.Peter Collingbourne2016-11-101-3/+15
| | | | | | | | | | | | | | | | | If the inrange keyword is present before any index, loading from or storing to any pointer derived from the getelementptr has undefined behavior if the load or store would access memory outside of the bounds of the element selected by the index marked as inrange. This can be used, e.g. for alias analysis or to split globals at element boundaries where beneficial. As previously proposed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2016-July/102472.html Differential Revision: https://reviews.llvm.org/D22793 llvm-svn: 286514
* [LangRef] Drop "experimental" caveat from operand bundlesSanjoy Das2016-11-101-3/+0
| | | | | | I think we're past that point now. llvm-svn: 286428
* DebugInfo: make DW_TAG_atomic_type validVictor Leschuk2016-10-311-2/+3
| | | | | | | | | | | | | | DW_TAG_atomic_type was already included in Dwarf.defs and emitted correctly, however Verifier didn't recognize it as valid. Thus we introduce the following changes: * Make DW_TAG_atomic_type valid tag for IR and DWARF (enabled only with -gdwarf-5) * Add it to related docs * Add DebugInfo tests Differential Revision: https://reviews.llvm.org/D26144 llvm-svn: 285624
* fix title underline lengthAlbert Gutowski2016-10-121-1/+1
| | | | llvm-svn: 284078
* Create llvm.addressofreturnaddress intrinsicAlbert Gutowski2016-10-121-0/+26
| | | | | | | | | | | | Summary: We need a new LLVM intrinsic to implement MS _AddressOfReturnAddress builtin on 64-bit Windows. Reviewers: majnemer, rnk Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D25293 llvm-svn: 284061
* [docs] Fix indentation bug in LangRef.Lang Hames2016-10-081-2/+2
| | | | llvm-svn: 283624
* Extend title underlineXinliang David Li2016-09-181-1/+1
| | | | llvm-svn: 281869
* [Profile] Implement select instruction instrumentation in IR PGOXinliang David Li2016-09-181-0/+31
| | | | | | Differential Revision: http://reviews.llvm.org/D23727 llvm-svn: 281858
* [LangRef] Add a clarifying example for undefSanjoy Das2016-09-151-0/+3
| | | | llvm-svn: 281570
* It should also be legal to pass a swifterror parameter to a call as a swifterrorArnold Schwaighofer2016-09-101-4/+5
| | | | | | | | argument. rdar://28233388 llvm-svn: 281147
* Remove restriction that 'sret' must be on the first parameterReid Kleckner2016-09-081-4/+3
| | | | | | | | | | On Windows, it is often applied to the second parameter, and the x86 backend is prepared to deal with sret appearing on any parameter. Other backends assume it only appears on parameter zero, but those are target-specific requirements, and not an IR-level rule. llvm-svn: 280951
* [LangRef] Clarify !invariant.load semantics.Geoff Berry2016-08-311-6/+4
| | | | | | Based on discussion on llvm-dev. llvm-svn: 280262
* docs: mention that clobbering output regs in inline asm is illegal.Peter Zotov2016-08-301-0/+3
| | | | | | | | | I've found this out the hard way; LLVM will not normally catch this error (unless -verify-machineinstrs is passed), and under certain very specific circumstances (such as register scavenger running under pressure) this would result in an opaque crash in codegen. llvm-svn: 280071
* Revert "Revert "Invariant start/end intrinsics overloaded for address space""Mehdi Amini2016-08-131-2/+4
| | | | | | This reverts commit 32fc6488e48eafc0ca1bac1bd9cbf0008224d530. llvm-svn: 278609
* Revert "Invariant start/end intrinsics overloaded for address space"Mehdi Amini2016-08-131-4/+2
| | | | | | This reverts commit r276447. llvm-svn: 278608
* [LangRef] Fix formatting (no semantic change)Sanjoy Das2016-08-101-5/+4
| | | | llvm-svn: 278294
* Revert "[X86] Support the "ms-hotpatch" attribute."Charles Davis2016-08-081-19/+1
| | | | | | | | This reverts commit r278048. Something changed between the last time I built this--it takes awhile on my ridiculously slow and ancient computer--and now that broke this. llvm-svn: 278053
* [X86] Support the "ms-hotpatch" attribute.Charles Davis2016-08-081-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Based on two patches by Michael Mueller. This is a target attribute that causes a function marked with it to be emitted as "hotpatchable". This particular mechanism was originally devised by Microsoft for patching their binaries (which they are constantly updating to stay ahead of crackers, script kiddies, and other ne'er-do-wells on the Internet), but is now commonly abused by Windows programs to hook API functions. This mechanism is target-specific. For x86, a two-byte no-op instruction is emitted at the function's entry point; the entry point must be immediately preceded by 64 (32-bit) or 128 (64-bit) bytes of padding. This padding is where the patch code is written. The two byte no-op is then overwritten with a short jump into this code. The no-op is usually a `movl %edi, %edi` instruction; this is used as a magic value indicating that this is a hotpatchable function. Reviewers: majnemer, sanjoy, rnk Subscribers: dberris, llvm-commits Differential Revision: https://reviews.llvm.org/D19908 llvm-svn: 278048
* [IR] Introduce a non-integral pointer typeSanjoy Das2016-07-281-0/+24
| | | | | | | | | | | | | | | Summary: This change adds a `ni` specifier in the `datalayout` string to denote pointers in some given address spaces as "non-integral", and adds some typing rules around these special pointers. Reviewers: majnemer, chandlerc, atrick, dberlin, eli.friedman, tstellarAMD, arsenm Subscribers: arsenm, mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D22488 llvm-svn: 277085
* fix some typos in the docSylvestre Ledru2016-07-281-1/+1
| | | | llvm-svn: 276968
* docs: Add reference to type metadata to langref.Peter Collingbourne2016-07-261-0/+4
| | | | llvm-svn: 276817
* Invariant start/end intrinsics overloaded for address spaceAnna Thomas2016-07-221-2/+4
| | | | | | | | | | | | | | | | | | | | | | Summary: The llvm.invariant.start and llvm.invariant.end intrinsics currently support specifying invariant memory objects only in the default address space. With this change, these intrinsics are overloaded for any adddress space for memory objects and we can use these llvm invariant intrinsics in non-default address spaces. Example: llvm.invariant.start.p1i8(i64 4, i8 addrspace(1)* %ptr) This overloaded intrinsic is needed for representing final or invariant memory in managed languages. Reviewers: apilipenko, reames Subscribers: llvm-commits llvm-svn: 276447
* Revert "Invariant start/end intrinsics overloaded for address space"Anna Thomas2016-07-211-4/+2
| | | | | | This reverts commit r276316. llvm-svn: 276320
* Invariant start/end intrinsics overloaded for address spaceAnna Thomas2016-07-211-2/+4
| | | | | | | | | | | | | | | | | | | | | Summary: The llvm.invariant.start and llvm.invariant.end intrinsics currently support specifying invariant memory objects only in the default address space. With this change, these intrinsics are overloaded for any adddress space for memory objects and we can use these llvm invariant intrinsics in non-default address spaces. Example: llvm.invariant.start.p1i8(i64 4, i8 addrspace(1)* %ptr) This overloaded intrinsic is needed for representing final or invariant memory in managed languages. Reviewers: tstellarAMD, reames, apilipenko Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D22519 llvm-svn: 276316
* [docs] Fixing Sphinx warnings to unclog the buildbotRenato Golin2016-07-201-63/+63
| | | | | | | | | | | | | | | | | | | | | | | Lots of blocks had "llvm" or "nasm" syntax types but either weren't following the syntax, or the syntax has changed (and sphinx hasn't keep up) or the type doesn't even exist (nasm?). Other documents had :options: what were invalid. I only removed those that had warnings, and left the ones that didn't, in order to follow the principle of least surprise. This is like this for ages, but the buildbot is now failing on errors. It may take a while to upgrade the buildbot's sphinx, if that's even possible, but that shouldn't stop us from getting docs updates (which seem down for quite a while). Also, we're not losing any syntax highlight, since when it doesn't parse, it doesn't colour. Ie. those blocks are not being highlighted anyway. I'm trying to get all docs in one go, so that it's easy to revert later if we do fix, or at least easy to know what's to fix. llvm-svn: 276109
* PR28516: Fix LangRef description of call and invoke to match IR changes for ↵David Blaikie2016-07-131-14/+16
| | | | | | typeless pointers llvm-svn: 275283
* Update the LangRef description of the 'returned' attributeHal Finkel2016-07-101-6/+7
| | | | | | | | | | | | The description of the 'returned' attribute says that it is only used when code-generating the caller. I'd like to make the optimizer smarter about looking through functions with returned arguments (generally, but motivated by my llvm.noalias work). As David pointed out in the review of D22202, the LangRef should be updated to make its expanded uses clearer. Differential Revision: http://reviews.llvm.org/D22205 llvm-svn: 275026
* NVPTX: Replace uses of cuda.syncthreads with nvvm.barrier0Justin Bogner2016-07-061-1/+1
| | | | | | | Everywhere where cuda.syncthreads or __syncthreads is used, use the properly namespaced nvvm.barrier0 instead. llvm-svn: 274664
* Add writeonly IR attributeNicolai Haehnle2016-07-041-0/+7
| | | | | | | | | | | | | | | | | Summary: This complements the earlier addition of IntrWriteMem and IntrWriteArgMem LLVM intrinsic properties, see D18291. Also start using the attribute for memset, memcpy, and memmove intrinsics, and remove their special-casing in BasicAliasAnalysis. Reviewers: reames, joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18714 llvm-svn: 274485
* fix some various typos in the docSylvestre Ledru2016-07-021-2/+2
| | | | llvm-svn: 274449
* Support arbitrary addrspace pointers in masked load/store intrinsicsArtur Pilipenko2016-06-281-10/+10
| | | | | | | | | | | | | | This is a resubmittion of 263158 change after fixing the existing problem with intrinsics mangling (see LTO and intrinsics mangling llvm-dev thread for details). This patch fixes the problem which occurs when loop-vectorize tries to use @llvm.masked.load/store intrinsic for a non-default addrspace pointer. It fails with "Calling a function with a bad signature!" assertion in CallInst constructor because it tries to pass a non-default addrspace pointer to the pointer argument which has default addrspace. The fix is to add pointer type as another overloaded type to @llvm.masked.load/store intrinsics. Reviewed By: reames Differential Revision: http://reviews.llvm.org/D17270 llvm-svn: 274043
* Verifier: Reject non-float !fpmathMatt Arsenault2016-06-271-2/+2
| | | | | | | Code already assumes this is float. getFPAccuracy() crashes on any other type. llvm-svn: 273912
* Revert -r273892 "Support arbitrary addrspace pointers in masked load/store ↵Artur Pilipenko2016-06-271-10/+10
| | | | | | intrinsics" since some of the clang tests don't expect to see the updated signatures. llvm-svn: 273895
* Support arbitrary addrspace pointers in masked load/store intrinsicsArtur Pilipenko2016-06-271-10/+10
| | | | | | | | | | | | | | This is a resubmittion of 263158 change after fixing the existing problem with intrinsics mangling (see LTO and intrinsics mangling llvm-dev thread for details). This patch fixes the problem which occurs when loop-vectorize tries to use @llvm.masked.load/store intrinsic for a non-default addrspace pointer. It fails with "Calling a function with a bad signature!" assertion in CallInst constructor because it tries to pass a non-default addrspace pointer to the pointer argument which has default addrspace. The fix is to add pointer type as another overloaded type to @llvm.masked.load/store intrinsics. Reviewed By: reames Differential Revision: http://reviews.llvm.org/D17270 llvm-svn: 273892
* IR: Introduce llvm.type.checked.load intrinsic.Peter Collingbourne2016-06-251-0/+54
| | | | | | | | | | | | | | | | This intrinsic safely loads a function pointer from a virtual table pointer using type metadata. This intrinsic is used to implement control flow integrity in conjunction with virtual call optimization. The virtual call optimization pass will optimize away llvm.type.checked.load intrinsics associated with devirtualized calls, thereby removing the type check in cases where it is not needed to enforce the control flow integrity constraint. This patch also introduces the capability to copy type metadata between global variables, and teaches the virtual call optimization pass to do so. Differential Revision: http://reviews.llvm.org/D21121 llvm-svn: 273756
* IR: New representation for CFI and virtual call optimization pass metadata.Peter Collingbourne2016-06-241-12/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bitset metadata currently used in LLVM has a few problems: 1. It has the wrong name. The name "bitset" refers to an implementation detail of one use of the metadata (i.e. its original use case, CFI). This makes it harder to understand, as the name makes no sense in the context of virtual call optimization. 2. It is represented using a global named metadata node, rather than being directly associated with a global. This makes it harder to manipulate the metadata when rebuilding global variables, summarise it as part of ThinLTO and drop unused metadata when associated globals are dropped. For this reason, CFI does not currently work correctly when both CFI and vcall opt are enabled, as vcall opt needs to rebuild vtable globals, and fails to associate metadata with the rebuilt globals. As I understand it, the same problem could also affect ASan, which rebuilds globals with a red zone. This patch solves both of those problems in the following way: 1. Rename the metadata to "type metadata". This new name reflects how the metadata is currently being used (i.e. to represent type information for CFI and vtable opt). The new name is reflected in the name for the associated intrinsic (llvm.type.test) and pass (LowerTypeTests). 2. Attach metadata directly to the globals that it pertains to, rather than using the "llvm.bitsets" global metadata node as we are doing now. This is done using the newly introduced capability to attach metadata to global variables (r271348 and r271358). See also: http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html Differential Revision: http://reviews.llvm.org/D21053 llvm-svn: 273729
* LangRef: Note expectations when loading with extra alignmentMatt Arsenault2016-06-161-2/+14
| | | | llvm-svn: 272914
* IR: Introduce local_unnamed_addr attribute.Peter Collingbourne2016-06-141-13/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
* [SystemZ] Enable index register memory constraints for inline ASMUlrich Weigand2016-06-131-4/+8
| | | | | | | | | | | | | | | | This enables use of the 'R' and 'T' memory constraints for inline ASM operands on SystemZ, which allow an index register as well as an immediate displacement. This patch includes corresponding documentation and test case updates. As with the last patch of this kind, I moved the 'm' constraint to the most general case, which is now 'T' (base + 20-bit signed displacement + index register). Author: colpell Differential Revision: http://reviews.llvm.org/D21239 llvm-svn: 272547
* Update call site attribute documentationMatt Arsenault2016-06-101-2/+2
| | | | | | convergent is also accepted. llvm-svn: 272353
OpenPOWER on IntegriCloud