summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Core.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Replace APFloatBase static fltSemantics data members with getter functionsStephan Bergmann2016-12-141-1/+1
| | | | | | | | | | | | | At least the plugin used by the LibreOffice build (<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly uses those members (through inline functions in LLVM/Clang include files in turn using them), but they are not exported by utils/extract_symbols.py on Windows, and accessing data across DLL/EXE boundaries on Windows is generally problematic. Differential Revision: https://reviews.llvm.org/D26671 llvm-svn: 289647
* IR: Change PointerType to derive from Type rather than SequentialType.Peter Collingbourne2016-12-021-2/+5
| | | | | | | | | | | | | | | | | | | As proposed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2016-October/106640.html This is for a couple of reasons: - Values of type PointerType are unlike the other SequentialTypes (arrays and vectors) in that they do not hold values of the element type. By moving PointerType we can unify certain aspects of how the other SequentialTypes are handled. - PointerType will have no place in the SequentialType hierarchy once pointee types are removed, so this is a necessary step towards removing pointee types. Differential Revision: https://reviews.llvm.org/D26595 llvm-svn: 288462
* [C API] Fix several null pointer dereferences.whitequark2016-11-121-0/+8
| | | | llvm-svn: 286704
* Split Bitcode/ReaderWriter.h into separate reader and writer headersTeresa Johnson2016-11-111-1/+1
| | | | | | | | | | | | | | | | | | | | | Summary: Split ReaderWriter.h which contains the APIs into both the BitReader and BitWriter libraries into BitcodeReader.h and BitcodeWriter.h. This is to address Chandler's concern about sharing the same API header between multiple libraries (BitReader and BitWriter). That concern is why we create a single bitcode library in our downstream build of clang, which led to r286297 being reverted as it added a dependency that created a cycle only when there is a single bitcode library (not two as in upstream). Reviewers: mehdi_amini Subscribers: dlj, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D26502 llvm-svn: 286566
* Kill deprecated attribute APIAmaury Sechet2016-11-061-66/+0
| | | | | | | | | | | | | | | Summary: This kill various depreacated API related to attribute : - The deprecated C API attribute based on LLVMAttribute enum. - The Raw attribute set format (planned to be removed in 4.0). Reviewers: bkramer, echristo, mehdi_amini, void Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D23039 llvm-svn: 286062
* [C API] Add LLVMConstExactUDiv and LLVMBuildExactUDiv functions.Manuel Jacob2016-10-041-0/+11
| | | | | | | | | | | | | | Summary: These are analog to the existing LLVMConstExactSDiv and LLVMBuildExactSDiv functions. Reviewers: deadalnix, majnemer Subscribers: majnemer, llvm-commits Differential Revision: https://reviews.llvm.org/D25259 llvm-svn: 283269
* IR: Don't cast the end iterator to Instruction*Duncan P. N. Exon Smith2016-08-111-2/+2
| | | | | | | | | | | End iterators are usually sentinels, not actually Instruction* at all. Stop casting to it just to get an iterator back. There is likely no observable functionality change here right now (although this is relying on UB, I doubt it was triggering anything), but I'll be removing the cast soon. llvm-svn: 278346
* Expose AttributeSetNode, use it to provide aggregate getter for attribute in ↵Amaury Sechet2016-07-211-0/+28
| | | | | | | | | | | | | | the C API. Summary: See D19181 for context. Reviewers: whitequark, Wallbraker, jyknight, echristo, bkramer, void Subscribers: mehdi_amini Differential Revision: http://reviews.llvm.org/D21265 llvm-svn: 276236
* Apply clang-tidy's modernize-loop-convert to most of lib/IR.Benjamin Kramer2016-06-261-2/+2
| | | | | | Only minor manual fixes. No functionality change intended. llvm-svn: 273813
* Add support for string attributes in the C API.Amaury Sechet2016-06-151-1/+23
| | | | | | | | | | | | Summary: As per title. This completes the C API Attribute support. Reviewers: Wallbraker, whitequark, echristo, rafael, jyknight Subscribers: mehdi_amini Differential Revision: http://reviews.llvm.org/D21365 llvm-svn: 272811
* Add support for callsite in the new C API for attributesAmaury Sechet2016-06-151-0/+18
| | | | | | | | | | | | Summary: The second consumer of attributes. Reviewers: Wallbraker, whitequark, echristo, rafael, jyknight Subscribers: mehdi_amini Differential Revision: http://reviews.llvm.org/D21266 llvm-svn: 272754
* Remove unused import. NFCAmaury Sechet2016-06-141-1/+0
| | | | llvm-svn: 272731
* IR: Introduce local_unnamed_addr attribute.Peter Collingbourne2016-06-141-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Change () to (void) in the C API.Amaury Sechet2016-06-121-1/+1
| | | | llvm-svn: 272506
* Make sure we have a Add/Remove/Has function for various thing that can have ↵Amaury Sechet2016-06-121-2/+68
| | | | | | | | | | | | | | attribute. Summary: This also deprecated the get attribute function familly. Reviewers: Wallbraker, whitequark, joker.eph, echristo, rafael, jyknight Subscribers: axw, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D19181 llvm-svn: 272504
* Extract renaming from D19181Amaury Sechet2016-05-231-7/+2
| | | | | | | | | | | | Summary: This needs to get in before anything is released concerning attribute. If the old name gets in the wild, then we are stuck with it forever. Putting it in its own diff should getting that part at least in fast. Reviewers: Wallbraker, whitequark, joker.eph, echristo, rafael, jyknight Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D20417 llvm-svn: 270452
* Return a StringRef from getSection.Rafael Espindola2016-05-111-1/+3
| | | | | | This is similar to how getName is handled. llvm-svn: 269218
* Properly name LLVMSetIsInBounds's argument. NFCAmaury Sechet2016-05-011-2/+2
| | | | llvm-svn: 268176
* Reformat LLVMConstPointerNull. NFCAmaury Sechet2016-04-251-2/+1
| | | | llvm-svn: 267484
* Style fix in Core.h / Core.cpp. NFCAmaury Sechet2016-04-231-14/+10
| | | | llvm-svn: 267257
* Add LLVMGetAttrKindID in the C API in order to facilitate migration away ↵Amaury Sechet2016-04-201-0/+14
| | | | | | | | | | | | | | | | | from LLVMAttribute Summary: LLVMAttribute has outlived its utility and is becoming a problem for C API users that what to use all the LLVM attributes. In order to help moving away from LLVMAttribute in a smooth manner, this diff introduce LLVMGetAttrKindIDInContext, which can be used instead of the enum values. See D18749 for reference. Reviewers: Wallbraker, whitequark, joker.eph, echristo, rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D19081 llvm-svn: 266842
* Nuke getGlobalContext() from LLVM (but the C API)Mehdi Amini2016-04-141-4/+4
| | | | | | | | | | The only use for getGlobalContext() is in the C API. Let's just move the static global here and nuke the C++ API. Differential Revision: http://reviews.llvm.org/D19094 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266380
* Revert "Add LLVMGetAttrKindIDInContext in the C API in order to facilitate ↵Amaury Sechet2016-04-131-12/+0
| | | | | | | | migration away from LLVMAttribute" This reverts commit 0bcfd95c268bcb180a525e1837e84475df8acdc7. llvm-svn: 266259
* Add LLVMGetAttrKindIDInContext in the C API in order to facilitate migration ↵Amaury Sechet2016-04-131-0/+12
| | | | | | | | | | | | | | away from LLVMAttribute Summary: LLVMAttribute has outlived its utility and is becoming a problem for C API users that what to use all the LLVM attributes. In order to help moving away from LLVMAttribute in a smooth manner, this diff introduce LLVMGetAttrKindIDInContext, which can be used instead of the enum values. Reviewers: Wallbraker, whitequark, joker.eph, echristo Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18749 llvm-svn: 266257
* [llvm-c] Expose LLVMContextGetDiagnostic{Handler,Context}Jeroen Ketema2016-04-081-1/+11
| | | | | | Differential Revision: http://reviews.llvm.org/D18820 llvm-svn: 265773
* [llvm-c] Add LLVMGetValueKind.Peter Zotov2016-04-061-0/+11
| | | | | | | | Patch by Nicole Mazzuca <npmazzuca@gmail.com>. Differential Revision: http://reviews.llvm.org/D18729 llvm-svn: 265608
* NFC: make AtomicOrdering an enum classJF Bastien2016-04-061-14/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In the context of http://wg21.link/lwg2445 C++ uses the concept of 'stronger' ordering but doesn't define it properly. This should be fixed in C++17 barring a small question that's still open. The code currently plays fast and loose with the AtomicOrdering enum. Using an enum class is one step towards tightening things. I later also want to tighten related enums, such as clang's AtomicOrderingKind (which should be shared with LLVM as a 'C++ ABI' enum). This change touches a few lines of code which can be improved later, I'd like to keep it as NFC for now as it's already quite complex. I have related changes for clang. As a follow-up I'll add: bool operator<(AtomicOrdering, AtomicOrdering) = delete; bool operator>(AtomicOrdering, AtomicOrdering) = delete; bool operator<=(AtomicOrdering, AtomicOrdering) = delete; bool operator>=(AtomicOrdering, AtomicOrdering) = delete; This is separate so that clang and LLVM changes don't need to be in sync. Reviewers: jyknight, reames Subscribers: jyknight, llvm-commits Differential Revision: http://reviews.llvm.org/D18775 llvm-svn: 265602
* [llvm-c] Expose LLVM{Get,Set}ModuleIdentifierPeter Zotov2016-04-051-0/+11
| | | | | | | | Patch by Nicole Mazzuca <npmazzuca@gmail.com>. Differential Revision: http://reviews.llvm.org/D18736 llvm-svn: 265394
* Style update in Core.h/Core.cpp . NFCAmaury Sechet2016-04-041-2/+2
| | | | llvm-svn: 265353
* Various style fix in Core.h/Core.cpp . NFCAmaury Sechet2016-04-031-7/+7
| | | | llvm-svn: 265277
* Expose IRBuilder::CreateAtomicCmpXchg as LLVMBuildAtomicCmpXchg in the C API.Mehdi Amini2016-03-191-0/+55
| | | | | | | | | | | | | Summary: Also expose getters and setters in the C API, so that the change can be tested. Reviewers: nhaehnle, axw, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18260 From: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> llvm-svn: 263886
* Use templated version of unwrap instead of cats in the Core.cpp. NFCAmaury Sechet2016-03-131-6/+7
| | | | llvm-svn: 263349
* Move LLVMConstStructInContext so that declarationa nd definition order ↵Amaury Sechet2016-03-131-8/+8
| | | | | | match. NFC llvm-svn: 263348
* Small formating change in Core.cpp . NFCAmaury Sechet2016-03-071-3/+1
| | | | llvm-svn: 262860
* Add support for invoke/landingpad/resume in C API testAmaury Sechet2016-02-181-0/+34
| | | | | | | | | | | | Summary: As per title. There was a lot of part missing in the C API, so I had to extend the invoke and landingpad API. Reviewers: echristo, joker.eph, Wallbraker Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D17359 llvm-svn: 261254
* Add support for memory operations (load/store/gep) in C API echo testAmaury Sechet2016-02-171-0/+12
| | | | | | | | | | | | Summary: As per title. Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D17245 llvm-svn: 261174
* Deprecate LLVMGetDataLayout and replace it by LLVMGetDataLayoutStrAmaury Sechet2016-02-161-1/+5
| | | | | | | | | | | | Summary: The name is confusing as it matche another method on the module. Reviewers: joker.eph, Wallbraker, echristo Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D17283 llvm-svn: 260920
* Rename LLVMSetDataLayout's argument to match what they stand forAmaury Sechet2016-02-151-2/+2
| | | | llvm-svn: 260916
* Add support for phi nodes in the LLVM C API testAmaury Sechet2016-02-111-0/+4
| | | | | | | | | | | | Summary: This required to add binding to Instruction::removeFromParent so that instruction can be forward declared and then moved at the right place. Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D17057 llvm-svn: 260597
* Add support for struct in C API testAmaury Sechet2016-02-101-0/+22
| | | | | | | | | | | | Summary: As per title. This also include extra support for insertvalue and extracvalue. Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D17055 llvm-svn: 260335
* Add binding for counting argument and find called value of call and invoke ↵Amaury Sechet2016-02-101-12/+11
| | | | | | | | | | | | instruction from the C API. Summary: As per title. This remove the need to rely on internal knowledge of call and invoke instruction to find called value and argument count. Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker Differential Revision: http://reviews.llvm.org/D17054 llvm-svn: 260332
* Add C binding for AllocaInst::getAllocatedTypeAmaury Sechet2016-02-091-0/+6
| | | | | | | | | | | | | | | Summary: Comes with an awesome test. Depends on D16912 Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16942 llvm-svn: 260313
* Improve the C API echo test tool to emit basic block is the right order.Amaury Sechet2016-02-091-0/+4
| | | | | | | | | | | | Summary: As per title. Also add a facility method to get the name of a basic block from the C API. Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16912 llvm-svn: 260309
* Remove static global GCNames from Function.cpp and move it to the ContextMehdi Amini2016-01-081-1/+1
| | | | | | | | | This remove the need for locking when deleting a function. Differential Revision: http://reviews.llvm.org/D15988 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 257139
* IR: Remove implicit iterator conversions from lib/IR, NFCDuncan P. N. Exon Smith2015-10-081-35/+35
| | | | | | | | | | | | | | | | | | | | | | | | Stop converting implicitly between iterators and pointers/references in lib/IR. For convenience, I've added a `getIterator()` accessor to `ilist_node` so that callers don't need to know how to spell the iterator class (i.e., they can use `X.getIterator()` instead of `Function::iterator(X)`). I'll eventually disallow these implicit conversions entirely, but there's a lot of code, so it doesn't make sense to do it all in one patch. One library or so at a time. Why? To root out cases of `getNextNode()` and `getPrevNode()` being used in iterator logic. The design of `ilist` makes that invalid when the current node could be at the back of the list, but it happens to "work" right now because of a bug where those functions never return `nullptr` if you're using a half-node sentinel. Before I can fix the function, I have to remove uses of it that rely on it misbehaving. (Maybe the function should just be deleted anyway? But I don't want deleting it -- potentially a huge project -- to block fixing ilist/iplist.) llvm-svn: 249782
* Revert "[opaque pointer type] Pass GlobalAlias the actual pointer type ↵David Blaikie2015-09-141-1/+2
| | | | | | | | | | | | | | | | | rather than decomposing it into pointee type + address space" This was a flawed change - it just caused the getElementType call to be deferred until later, when we really need to remove it. Now that the IR for GlobalAliases has been updated, the root cause is addressed that way instead and this change is no longer needed (and in fact gets in the way - because we want to pass the pointee type directly down further). Follow up patches to push this through GlobalValue, bitcode format, etc, will come along soon. This reverts commit 236160. llvm-svn: 247585
* [IR] Add token typesDavid Majnemer2015-08-141-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces the basic functionality to support "token types". The motivation stems from the need to perform operations on a Value whose provenance cannot be obscured. There are several applications for such a type but my immediate motivation stems from WinEH. Our personality routine enforces a single-entry - single-exit regime for cleanups. After several rounds of optimizations, we may be left with a terminator whose "cleanup-entry block" is not entirely clear because control flow has merged two cleanups together. We have experimented with using labels as operands inside of instructions which are not terminators to indicate where we came from but found that LLVM does not expect such exotic uses of BasicBlocks. Instead, we can use this new type to clearly associate the "entry point" and "exit point" of our cleanup. This is done by having the cleanuppad yield a Token and consuming it at the cleanupret. The token type makes it impossible to obscure or otherwise hide the Value, making it trivial to track the relationship between the two points. What is the burden to the optimizer? Well, it turns out we have already paid down this cost by accepting that there are certain calls that we are not permitted to duplicate, optimizations have to watch out for such instructions anyway. There are additional places in the optimizer that we will probably have to update but early examination has given me the impression that this will not be heroic. Differential Revision: http://reviews.llvm.org/D11861 llvm-svn: 245029
* Add support to set/get ordering for load/store from the C APIAndrew Wilkins2015-08-021-1/+34
| | | | | | | | | | | | Summary: As per title Reviewers: chandlerc, bogner, majnemer, axw Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11141 llvm-svn: 243847
* Revert "Update LLVM bindings after r239940. ..."Reid Kleckner2015-07-161-1/+8
| | | | | | | | | | | Revert the changes to the C API LLVMBuildLandingPad that were part of the personality function move. We now set the personality on the parent function when the C API attempts to construct a landingpad with a personality. This reverts commit r240010. llvm-svn: 242372
* Add capability to get and set the personalitty function from the C APIAndrew Wilkins2015-07-141-0/+8
| | | | | | | | | | | | | | | Summary: The capability was lost with D10429 where the personality function was set at function level rather than landing pad level. Now there is no way to get/set the personality function from the C API. That is a problem. Note that the whole thing could be avoided by improving the C API testing, as started by D10725 Reviewers: chandlerc, bogner, majnemer, andrew.w.kaylor, rafael, rnk, axw Subscribers: rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D10946 llvm-svn: 242104
OpenPOWER on IntegriCloud