summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/ConstantsContext.h
Commit message (Collapse)AuthorAgeFilesLines
* [ConstantFold][SVE] Fix constant folding for shufflevector.Eli Friedman2019-12-091-1/+1
| | | | | | | Don't try to fold away shuffles which can't be folded. Fix creation of shufflevector constant expressions. Differential Revision: https://reviews.llvm.org/D71147
* Fix cppcheck variable shadow warning. NFCI.Simon Pilgrim2019-09-251-3/+3
| | | | llvm-svn: 372872
* Add missing ExplicitTy default initialization to ConstantExprKeyType ↵Simon Pilgrim2019-09-251-2/+4
| | | | | | | | constructors. Fixes cppcheck uninitialized variable warnings llvm-svn: 372871
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [IR] Add a dedicated FNeg IR InstructionCameron McInally2018-11-131-1/+3
| | | | | | | | | | | The IEEE-754 Standard makes it clear that fneg(x) and fsub(-0.0, x) are two different operations. The former is a bitwise operation, while the latter is an arithmetic operation. This patch creates a dedicated FNeg IR Instruction to model that behavior. Differential Revision: https://reviews.llvm.org/D53877 llvm-svn: 346774
* Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen2018-05-141-1/+3
| | | | | | | | | | | | | | | | The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it. In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one. Differential Revision: https://reviews.llvm.org/D43624 llvm-svn: 332240
* [IR] Stop deleting other signatures of User::operator new when we override ↵Craig Topper2017-06-121-18/+0
| | | | | | | | | | | | | | | | | | one signature in a class derived from User User has 3 signatures for operator new today. They take a single size, a size and a number of users, and a size, number of users, and descriptor size. Historically there used to only be one signature that took size and a number of uses. Long ago derived classes implemented their own versions that took just a size and would call the size and use count version. Then they left an unimplemented signature for the size and use count signature from User. As we moved to C++11 this unimplemented signature because = delete. Since then operator new has picked up two new signatures for operator new. But when the 3 argument version was added it was never added to the delete list in all of the derived classes where the 2 argument version is deleted. This makes things inconsistent. I believe once one version of operator new is created in a derived class name hiding will take care of making all of the base class signatures unavailable. So I don't think the deleted lines are needed at all. This patch removes all of the deletes in cases where there is an override or there is already a delete of another signature (that should trigger name hiding too). Differential Revision: https://reviews.llvm.org/D34120 llvm-svn: 305251
* [IR] De-virtualize ~Value to save a vptrReid Kleckner2017-05-181-20/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Implements PR889 Removing the virtual table pointer from Value saves 1% of RSS when doing LTO of llc on Linux. The impact on time was positive, but too noisy to conclusively say that performance improved. Here is a link to the spreadsheet with the original data: https://docs.google.com/spreadsheets/d/1F4FHir0qYnV0MEp2sYYp_BuvnJgWlWPhWOwZ6LbW7W4/edit?usp=sharing This change makes it invalid to directly delete a Value, User, or Instruction pointer. Instead, such code can be rewritten to a null check and a call Value::deleteValue(). Value objects tend to have their lifetimes managed through iplist, so for the most part, this isn't a big deal. However, there are some places where LLVM deletes values, and those places had to be migrated to deleteValue. I have also created llvm::unique_value, which has a custom deleter, so it can be used in place of std::unique_ptr<Value>. I had to add the "DerivedUser" Deleter escape hatch for MemorySSA, which derives from User outside of lib/IR. Code in IR cannot include MemorySSA headers or call the MemoryAccess object destructors without introducing a circular dependency, so we need some level of indirection. Unfortunately, no class derived from User may have any virtual methods, because adding a virtual method would break User::getHungOffOperands(), which assumes that it can find the use list immediately prior to the User object. I've added a static_assert to the appropriate OperandTraits templates to help people avoid this trap. Reviewers: chandlerc, mehdi_amini, pete, dberlin, george.burgess.iv Reviewed By: chandlerc Subscribers: krytarowski, eraman, george.burgess.iv, mzolotukhin, Prazek, nlewycky, hans, inglorion, pcc, tejohnson, dberlin, llvm-commits Differential Revision: https://reviews.llvm.org/D31261 llvm-svn: 303362
* [IR] Fix some Clang-tidy modernize-use-using warnings; other minor fixes (NFC).Eugene Zelenko2017-05-151-19/+30
| | | | llvm-svn: 303119
* [ADT, IR] Fix some Clang-tidy modernize-use-equals-delete and Include What ↵Eugene Zelenko2016-12-071-50/+112
| | | | | | You Use warnings; other minor fixes (NFC). llvm-svn: 288989
* Increase SmallVector size for ConstantUniqueMap::getHashValue() (NFC)Mehdi Amini2016-04-191-1/+1
| | | | | | | | This remove totally any malloc from this function on my profile (from 155k before). From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266700
* [NFC] Header cleanupMehdi Amini2016-04-181-2/+0
| | | | | | | | | | | | | | Removed some unused headers, replaced some headers with forward class declarations. Found using simple scripts like this one: clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap' Patch by Eugene Kosov <claprix@yandex.ru> Differential Revision: http://reviews.llvm.org/D19219 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266595
* IR: Use DenseSet instead of DenseMap for ConstantUniqueMap; NFCDuncan P. N. Exon Smith2016-04-061-11/+10
| | | | | | | | | | | | | | | | | | Use a DenseSet instead of a DenseMap for constants in LLVMContextImpl. Last time I looked at this was some time before r223588, when DenseSet<V> had no advantage over DenseMap<V,char>. After r223588, there's a 50% memory savings. This is all mechanical. There were little bits of missing API from DenseSet so I added the trivial implementations: - iterator::operator++(int) - template <class LookupKeyT> insert_as(ValueTy, LookupKeyT) There should be no functionality change, just reduced memory consumption (this wasn't on a profile or anything; just a cleanup I stumbled on). llvm-svn: 265577
* Add a new insert_as() method to DenseMap and use it for ConstantUniqueMapMehdi Amini2016-03-071-17/+23
| | | | | | | | | | | | | | | | | | | Just like the existing find_as() method, the new insert_as() accepts an extra parameter which is used as a key to find the bucket in the map. When creating a Constant, we want to check the map before actually creating the object. In this case we have to perform two queries to the map, and this extra parameter can save recomputing the hash value for the second query. This is a reapply of r260458, that was reverted because it was suspected to be the cause of instability of an internal bot, but wasn't confirmed. Differential Revision: http://reviews.llvm.org/D16268 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 262812
* Revert "Add a new insert_as() method to DenseMap and use it for ↵Mehdi Amini2016-02-111-23/+17
| | | | | | | | | | | | | ConstantUniqueMap" This reverts commit r260458. It was backported on an internal branch and broke stage2 build. Since this can lead to weird random crash I'm reverting upstream as well while investigating. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 260605
* Add a new insert_as() method to DenseMap and use it for ConstantUniqueMapMehdi Amini2016-02-101-17/+23
| | | | | | | | | | | | | | | | | | | | Summary: Just like the existing find_as() method, the new insert_as() accepts an extra parameter which is used as a key to find the bucket in the map. When creating a Constant, we want to check the map before actually creating the object. In this case we have to perform two queries to the map, and this extra parameter can save recomputing the hash value for the second query. Reviewers: dexonsmith, chandlerc Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16268 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 260458
* [opaque pointer types] [NFC] GEP: replace get(Pointer)ElementType uses with ↵Eduard Burtescu2016-01-191-8/+2
| | | | | | | | | | | | | | | | | | get{Source,Result}ElementType. Summary: GEPOperator: provide getResultElementType alongside getSourceElementType. This is made possible by adding a result element type field to GetElementPtrConstantExpr, which GetElementPtrInst already has. GEP: replace get(Pointer)ElementType uses with get{Source,Result}ElementType. Reviewers: mjacob, dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16275 llvm-svn: 258145
* [IR] Add classof for GetElementPtrConstantExpr, CompareConstantExpr, ↵Craig Topper2015-12-151-0/+29
| | | | | | | | InsertValueConstantExpr, and ExtractValueConstantExpr. All but CompareConstantExpr were being used in casts that were erroneously using ConstantExpr::classof due to inheritance. While there use cast<CompareConstantExpr> to simplify code slightly. I believe in one place we were always casting to ExtractValueConstantExpr when we were trying to choose between ExtractValueConstantExpr and InsertValueConstantExpr because of this. But since they have identical layouts this didn't cause any observable problems. llvm-svn: 255624
* [opaque pointer type] Avoid using pointee types to retrieve InlineAsm's ↵David Blaikie2015-07-281-7/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | function type As a stop-gap, retrieving the InlineAsm's function type was done via the pointee type of its (pointer) Value type. Instead, pass down and store the FunctionType in the InlineAsm object. The only wrinkle with this is the ConstantUniqueMap, which then needs to ferry the FunctionType down through the InlineAsmKeyType. This could be done a bit differently if the ConstantInfo trait were broadened a bit to provide an extension point for access to the TypeClass object from the ValType objects, so that the ConstantUniqueMap<InlineAsm> would then be keyed on FunctionTypes instead of PointerTypes that point to FunctionTypes. This drops the number of IR tests that don't roundtrip through bitcode* without calling PointerType::getElementType from 416 to 8 (out of 10733). 3 of those crash when roundtripping at ToT anyway. * modulo various unavoidable uses of pointer types when validating IR (for now) and in the way globals are parsed, unfortunately. These cases will either go away (because such validation will no longer be necessary or possible when pointee types are opaque), or have to be made simultaneously with the removal of pointee types. llvm-svn: 243356
* Fix some odd whitespace and formatting errors while makingEric Christopher2015-05-181-35/+23
| | | | | | changes in ConstantsContext.h. llvm-svn: 237620
* [opaque pointer type] Explicit pointee type for GEPOperator/GEPConstantExpr.David Blaikie2015-05-081-8/+24
| | | | | | | Also a couple of other changes to avoid use of PointerType::getElementType here & there too. llvm-svn: 236799
* Removing LLVM_DELETED_FUNCTION, as MSVC 2012 was the last reason for ↵Aaron Ballman2015-02-151-9/+9
| | | | | | requiring the macro. NFC; LLVM edition. llvm-svn: 229340
* IR: De-duplicate code for replacing operands in placeDuncan P. N. Exon Smith2014-08-191-0/+32
| | | | | | | This is non-trivial and sits in three places. Move it to ConstantUniqueMap. llvm-svn: 216007
* Reapply r215966, r215965, r215964, r215963, r215960, r215959, r215958, and ↵Duncan P. N. Exon Smith2014-08-191-363/+201
| | | | | | | | | | | | r215957 This reverts commit r215981, which reverted the above commits because MSVC std::equal asserts on nullptr iterators, and thes commits introduced an `ArrayRef::equals()` on empty ArrayRefs. ArrayRef was changed not to use std::equal in r215986. llvm-svn: 215987
* Reverting r215966, r215965, r215964, r215963, r215960, r215959, r215958, and ↵Aaron Ballman2014-08-191-201/+363
| | | | | | r215957 (these commits all rely on previous commits) due to build breakage. These commits cause failed assertions when testing Clang using MSVC 2013. The asserts are triggered from the std::equal call within ArrayRef::equals due to being passed invalid input (ArrayRef.begin() is returning a nullptr which is problematic). llvm-svn: 215981
* IR: Replace uses of ConstantAggrUniqueMap with ConstantUniqueMapDuncan P. N. Exon Smith2014-08-191-160/+45
| | | | | | | Now that `ConstantAggrUniqueMap` and `ConstantUniqueMap` work the same way, change the aggregates to use the new one. llvm-svn: 215959
* Remove extraneous typenames from r215957Duncan P. N. Exon Smith2014-08-191-2/+2
| | | | llvm-svn: 215958
* IR: Rewrite ConstantUniqueMapDuncan P. N. Exon Smith2014-08-191-250/+203
| | | | | | | | | | | | | | | | | | | | | Rewrite `ConstantUniqueMap` to be more similar to `ConstantAggrUniqueMap`. - Use a `DenseMap` with custom MapInfo instead of a `std::map` with linear lookups and deletion. - Don't waste memory explicitly storing (heavyweight) keys. Only `ConstantExpr` and `InlineAsm` actually use this data structure, so I also updated them to use it. This code cleanup is a precursor to reducing RAUW traffic on `ConstantExpr` -- I felt badly adding a new (linear) call to `ConstantUniqueMap::FindExistingKey`, so this designs away the concern. A follow-up commit will transition the users of `ConstantAggrUniqueMap` over. llvm-svn: 215957
* IR: ArrayRef-ize {Insert,Extract}ValueConstantExpr constructorsDuncan P. N. Exon Smith2014-08-191-8/+6
| | | | | | No functionality change. llvm-svn: 215955
* Prevent clang-format from moving the namespace closing brace, NFCDuncan P. N. Exon Smith2014-08-191-1/+1
| | | | llvm-svn: 215954
* Canonicalize header guards into a common format.Benjamin Kramer2014-08-131-2/+2
| | | | | | | | | | Add header guards to files that were missing guards. Remove #endif comments as they don't seem common in LLVM (we can easily add them back if we decide they're useful) Changes made by clang-tidy with minor tweaks. llvm-svn: 215558
* Try to fix the msvc build.Benjamin Kramer2014-04-291-0/+1
| | | | llvm-svn: 207594
* [C++] Use 'nullptr'.Craig Topper2014-04-281-2/+2
| | | | llvm-svn: 207394
* [Modules] Make Support/Debug.h modular. This requires it to not changeChandler Carruth2014-04-211-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | behavior based on other files defining DEBUG_TYPE, which means it cannot define DEBUG_TYPE at all. This is actually better IMO as it forces folks to define relevant DEBUG_TYPEs for their files. However, it requires all files that currently use DEBUG(...) to define a DEBUG_TYPE if they don't already. I've updated all such files in LLVM and will do the same for other upstream projects. This still leaves one important change in how LLVM uses the DEBUG_TYPE macro going forward: we need to only define the macro *after* header files have been #include-ed. Previously, this wasn't possible because Debug.h required the macro to be pre-defined. This commit removes that. By defining DEBUG_TYPE after the includes two things are fixed: - Header files that need to provide a DEBUG_TYPE for some inline code can do so by defining the macro before their inline code and undef-ing it afterward so the macro does not escape. - We no longer have rampant ODR violations due to including headers with different DEBUG_TYPE definitions. This may be mostly an academic violation today, but with modules these types of violations are easy to check for and potentially very relevant. Where necessary to suppor headers with DEBUG_TYPE, I have moved the definitions below the includes in this commit. I plan to move the rest of the DEBUG_TYPE macros in LLVM in subsequent commits; this one is big enough. The comments in Debug.h, which were hilariously out of date already, have been updated to reflect the recommended practice going forward. llvm-svn: 206822
* [C++11] Add 'override' keyword to IR library.Craig Topper2014-03-051-10/+10
| | | | llvm-svn: 202939
* [C++11] Use std::tie to simplify compare operators.Benjamin Kramer2014-03-031-19/+8
| | | | | | No functionality change. llvm-svn: 202751
* Revert "Give internal classes hidden visibility."Benjamin Kramer2013-09-111-14/+14
| | | | | | | It works with clang, but GCC has different rules so we can't make all of those hidden. This reverts commit r190534. llvm-svn: 190536
* Give internal classes hidden visibility.Benjamin Kramer2013-09-111-14/+14
| | | | | | Worth 100k on a linux/x86_64 Release+Asserts clang. llvm-svn: 190534
* Add ArrayRef constructor from None, and do the cleanups that this ↵Dmitri Gribenko2013-05-051-1/+1
| | | | | | | | constructor enables Patch by Robert Wilhelm. llvm-svn: 181138
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-3/+3
| | | | | | | | | | | | | | | | | | | | | into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
* Rename VMCore directory to IR.Chandler Carruth2013-01-021-0/+774
Aside from moving the actual files, this patch only updates the build system and the source file comments under lib/... that are relevant. I'll be updating other docs and other files in smaller subsequnet commits. While I've tried to test this, but it is entirely possible that there will still be some build system fallout. Also, note that I've not changed the library name itself: libLLVMCore.a is still the library name. I'd be interested in others' opinions about whether we should rename this as well (I think we should, just not sure what it might break) llvm-svn: 171359
OpenPOWER on IntegriCloud