summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/DataLayout.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Use uniform mechanism for OOM errors handlingSerge Pavlov2018-06-091-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a recommit of r333506, which was reverted in r333518. The original commit message is below. In r325551 many calls of malloc/calloc/realloc were replaces with calls of their safe counterparts defined in the namespace llvm. There functions generate crash if memory cannot be allocated, such behavior facilitates handling of out of memory errors on Windows. If the result of *alloc function were checked for success, the function was not replaced with the safe variant. In these cases the calling function made the error handling, like: T *NewElts = static_cast<T*>(malloc(NewCapacity*sizeof(T))); if (NewElts == nullptr) report_bad_alloc_error("Allocation of SmallVector element failed."); Actually knowledge about the function where OOM occurred is useless. Moreover having a single entry point for OOM handling is convenient for investigation of memory problems. This change removes custom OOM errors handling and replaces them with calls to functions `llvm::safe_*alloc`. Declarations of `safe_*alloc` are moved to a separate include file, to avoid cyclic dependency in SmallVector.h Differential Revision: https://reviews.llvm.org/D47440 llvm-svn: 334344
* Revert commit 333506Serge Pavlov2018-05-301-2/+4
| | | | | | | It looks like this commit is responsible for the fail: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/24382. llvm-svn: 333518
* Use uniform mechanism for OOM errors handlingSerge Pavlov2018-05-301-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a recommit of r333390, which was reverted in r333395, because it caused cyclic dependency when building shared library `LLVMDemangle.so`. In this commit `ItaniumDemangler.cpp` was not changed. The original commit message is below. In r325551 many calls of malloc/calloc/realloc were replaces with calls of their safe counterparts defined in the namespace llvm. There functions generate crash if memory cannot be allocated, such behavior facilitates handling of out of memory errors on Windows. If the result of *alloc function were checked for success, the function was not replaced with the safe variant. In these cases the calling function made the error handling, like: T *NewElts = static_cast<T*>(malloc(NewCapacity*sizeof(T))); if (NewElts == nullptr) report_bad_alloc_error("Allocation of SmallVector element failed."); Actually knowledge about the function where OOM occurred is useless. Moreover having a single entry point for OOM handling is convenient for investigation of memory problems. This change removes custom OOM errors handling and replaces them with calls to functions `llvm::safe_*alloc`. Declarations of `safe_*alloc` are moved to a separate include file, to avoid cyclic dependency in SmallVector.h Differential Revision: https://reviews.llvm.org/D47440 llvm-svn: 333506
* Reverted commits 333390, 333391 and 333394Serge Pavlov2018-05-291-2/+4
| | | | | | Build of shared library LLVMDemangle.so fails due to dependency problem. llvm-svn: 333395
* Use uniform mechanism for OOM errors handlingSerge Pavlov2018-05-291-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | In r325551 many calls of malloc/calloc/realloc were replaces with calls of their safe counterparts defined in the namespace llvm. There functions generate crash if memory cannot be allocated, such behavior facilitates handling of out of memory errors on Windows. If the result of *alloc function were checked for success, the function was not replaced with the safe variant. In these cases the calling function made the error handling, like: T *NewElts = static_cast<T*>(malloc(NewCapacity*sizeof(T))); if (NewElts == nullptr) report_bad_alloc_error("Allocation of SmallVector element failed."); Actually knowledge about the function where OOM occurred is useless. Moreover having a single entry point for OOM handling is convenient for investigation of memory problems. This change removes custom OOM errors handling and replaces them with calls to functions `llvm::safe_*alloc`. Declarations of `safe_*alloc` are moved to a separate include file, to avoid cyclic dependency in SmallVector.h Differential Revision: https://reviews.llvm.org/D47440 llvm-svn: 333390
* Add default address space for functions to the data layout (1/3)Dylan McKay2018-02-191-3/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This adds initial support for letting targets specify which address spaces their functions should reside in by default. If a function is created by a frontend, it will get the default address space specified in the DataLayout, unless the frontend explicitly uses a more general `llvm::Function` constructor. Function address spaces will become a part of the bitcode and textual IR forms, as we do not have access to a data layout whilst parsing LL. It will be possible to write IR that explicitly has `addrspace(n)` on a function. In this case, the function will reside in the specified space, ignoring the default in the DL. This is the first step towards placing functions into the correct address space for Harvard architectures. Full patchset * Add program address space to data layout D37052 * Require address space to be specified when creating functions D37054 * [clang] Require address space to be specified when creating functions D37057 Reviewers: pcc, arsenm, kparzysz, hfinkel, theraven Reviewed By: theraven Subscribers: arichardson, simoncook, rengolin, wdng, uabelho, bjope, asb, llvm-commits Differential Revision: https://reviews.llvm.org/D37052 llvm-svn: 325479
* Adding a width of the GEP index to the Data Layout.Elena Demikhovsky2018-02-141-10/+51
| | | | | | | | | | | | | | | | | | Making a width of GEP Index, which is used for address calculation, to be one of the pointer properties in the Data Layout. p[address space]:size:memory_size:alignment:pref_alignment:index_size_in_bits. The index size parameter is optional, if not specified, it is equal to the pointer size. Till now, the InstCombiner normalized GEPs and extended the Index operand to the pointer width. It works fine if you can convert pointer to integer for address calculation and all registered targets do this. But some ISAs have very restricted instruction set for the pointer calculation. During discussions were desided to retrieve information for GEP index from the Data Layout. http://lists.llvm.org/pipermail/llvm-dev/2018-January/120416.html I added an interface to the Data Layout and I changed the InstCombiner and some other passes to take the Index width into account. This change does not affect any in-tree target. I added tests to cover data layouts with explicitly specified index size. Differential Revision: https://reviews.llvm.org/D42123 llvm-svn: 325102
* Support, IR, ADT: Check nullptr after allocation with malloc/realloc or callocMatthias Braun2017-07-201-0/+2
| | | | | | | | | | | | As a follow up of the bad alloc handler patch, this patch introduces nullptr checks on pointers returned from the malloc/realloc/calloc functions. In addition some memory size assignments are moved behind the allocation of the corresponding memory to fulfill exception safe memory management (RAII). patch by Klaus Kretzschmar Differential Revision: https://reviews.llvm.org/D35414 llvm-svn: 308576
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* [DataLayout] Add llvm_unreachable to the default of a nested switch ↵Craig Topper2017-05-221-1/+1
| | | | | | statement that covers all values given to it by the outer switch. NFC llvm-svn: 303571
* [IR] Fix some Clang-tidy modernize-use-using warnings; other minor fixes (NFC).Eugene Zelenko2017-05-051-12/+15
| | | | llvm-svn: 302310
* [DataLayout] Removed default value from a variable that isn't used without ↵Craig Topper2017-04-191-3/+2
| | | | | | being overwritten. Make variable an enum instead of an int to avoid a cast later. NFC llvm-svn: 300634
* [IR] Implement DataLayout::getPointerTypeSizeInBits using ↵Craig Topper2017-04-171-5/+2
| | | | | | | | | | | | | | getPointerSizeInBits directly Currently we use getTypeSizeInBits which contains a switch statement to dispatch based on what the Type is. We know we always have a pointer type here, but the compiler isn't able to figure out that out to remove the switch. This patch changes it to just call handle the pointer type directly by calling getPointerSizeInBits without going through a switch. getPointerTypeSizeInBits is called pretty often, particularly by getOrEnforceKnownAlignment which is used by InstCombine. This should speed that up a little bit. Differential Revision: https://reviews.llvm.org/D31841 llvm-svn: 300475
* Allow DataLayout to specify addrspace for allocas.Matt Arsenault2017-04-101-0/+8
| | | | | | | | | | | | | | | | | | | | | | | LLVM makes several assumptions about address space 0. However, alloca is presently constrained to always return this address space. There's no real way to avoid using alloca, so without this there is no way to opt out of these assumptions. The problematic assumptions include: - That the pointer size used for the stack is the same size as the code size pointer, which is also the maximum sized pointer. - That 0 is an invalid, non-dereferencable pointer value. These are problems for AMDGPU because alloca is used to implement the private address space, which uses a 32-bit index as the pointer value. Other pointers are 64-bit and behave more like LLVM's notion of generic address space. By changing the address space used for allocas, we can change our generic pointer type to be LLVM's generic pointer type which does have similar properties. llvm-svn: 299888
* [IR] Use a binary search in DataLayout::getAlignmentInfoCraig Topper2017-03-231-58/+47
| | | | | | | | | | | | | | | | | | | | | Summary: We currently do a linear scan through all of the Alignments array entries anytime getAlignmentInfo is called. I noticed while profiling compile time on a -O2 opt run that this function can be called quite frequently and was showing about as about 1% of the time in callgrind. This patch puts the Alignments array into a sorted order by type and then by bitwidth. We can then do a binary search. And use the sorted nature to handle the special cases for INTEGER_ALIGN. Some of this is modeled after the sorting/searching we do for pointers already. This reduced the time spent in this routine by about 2/3 in the one compilation I was looking at. We could maybe improve this more by using a DenseMap to cache the results, but just sorting was easy and didn't require extra data structure. And I think it made the integer handling simpler. Reviewers: sanjoy, davide, majnemer, resistor, arsenm, mehdi_amini Reviewed By: arsenm Subscribers: arsenm, llvm-commits Differential Revision: https://reviews.llvm.org/D31232 llvm-svn: 298579
* [IR] Remove validAlignment and validPointer methods DataLayout as they ↵Craig Topper2017-03-211-6/+0
| | | | | | | | aren't used. I don't think validAlignment has been used since r34358 in 2007. I think validPointer was copied from validAlignment some time later, but it definitely wasn't used in the first commit that contained it. llvm-svn: 298458
* IR: Change the gep_type_iterator API to avoid always exposing the "current" ↵Peter Collingbourne2016-12-021-6/+3
| | | | | | | | | | | | | type. Instead, expose whether the current type is an array or a struct, if an array what the upper bound is, and if a struct the struct type itself. This is in preparation for a later change which will make PointerType derive from Type rather than SequentialType. Differential Revision: https://reviews.llvm.org/D26594 llvm-svn: 288458
* [IR/DataLayout] Simplify the code using PowerOf2Ceil. NFCI.Davide Italiano2016-11-111-6/+2
| | | | llvm-svn: 286554
* [IR] Introduce a non-integral pointer typeSanjoy Das2016-07-281-0/+14
| | | | | | | | | | | | | | | 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
* [IR] Make getIndexedOffsetInType return a signed resultDavid Majnemer2016-07-131-5/+5
| | | | | | | A GEPed offset can go negative, the result of getIndexedOffsetInType should according be a signed type. llvm-svn: 275246
* Rename getLargestLegalIntTypeSize to getLargestLegalIntTypeSizeInBits(). NFC.Jun Bum Lim2016-05-131-1/+1
| | | | | | | | | | | | Summary: Rename DataLayout::getLargestLegalIntTypeSize to DataLayout::getLargestLegalIntTypeSizeInBits() to prevent similar mistakes fixed in r269433. Reviewers: joker.eph, mcrosier Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D20248 llvm-svn: 269456
* Replace Type::getInt32Ty() and comparison by isIntegerTy(32). NFC.Manuel Jacob2016-01-221-3/+1
| | | | llvm-svn: 258480
* [opaque pointer types] [NFC] DataLayout::getIndexedOffset: take source ↵Eduard Burtescu2016-01-221-19/+12
| | | | | | | | | | | | | | element type instead of pointer type and rename to getIndexedOffsetInType. Summary: Reviewers: mjacob, dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16282 llvm-svn: 258478
* [opaque pointer types] [NFC] gep_type_{begin,end} now take source element ↵Eduard Burtescu2016-01-221-1/+4
| | | | | | | | | | | | type and address space. Reviewers: mjacob, dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16436 llvm-svn: 258474
* GlobalValue: use getValueType() instead of getType()->getPointerElementType().Manuel Jacob2016-01-161-1/+1
| | | | | | | | | | | | Reviewers: mjacob Subscribers: jholewinski, arsenm, dsanders, dblaikie Patch by Eduard Burtescu. Differential Revision: http://reviews.llvm.org/D16260 llvm-svn: 257999
* Update to use new name alignTo().Rui Ueyama2016-01-141-2/+2
| | | | llvm-svn: 257804
* Instcombine: destructor loads of structs that do not contains paddingMehdi Amini2015-12-151-2/+7
| | | | | | | | | | | | | | | | | | | | For non padded structs, we can just proceed and deaggregate them. We don't want ot do this when there is padding in the struct as to not lose information about this padding (the subsequents passes would then try hard to preserve the padding, which is undesirable). Also update extractvalue.ll and cast.ll so that they use structs with padding. Remove the FIXME in the extractvalue of laod case as the non padded case is handled when processing the load, and we don't want to do it on the padded case. Patch by: Amaury SECHET <deadalnix@gmail.com> Differential Revision: http://reviews.llvm.org/D14483 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 255600
* Revert "Add const to a bunch of Type* in DataLayout. NFC."Pete Cooper2015-07-271-13/+13
| | | | | | | | This reverts commit r243135. Feedback from Craig Topper and David Blaikie was that we don't put const on Type as it has no mutable state. llvm-svn: 243283
* Add const to a bunch of Type* in DataLayout. NFC.Pete Cooper2015-07-241-13/+13
| | | | | | | | Almost all methods in DataLayout took mutable pointers but didn't need to. These were only accessing constant methods of the types, or using the Type* to key a map. Neither of these needs a mutable pointer. llvm-svn: 243135
* fix formatting; NFCSanjay Patel2015-07-211-2/+2
| | | | llvm-svn: 242796
* COFF: Let globals with private linkage reside in their own sectionDavid Majnemer2015-03-171-3/+6
| | | | | | | | | | COFF COMDATs (for selection kinds other than 'select any') require at least one non-section symbol in the symbol table. Satisfy this by morally enhancing the linkage from private to internal. Differential Revision: http://reviews.llvm.org/D8394 llvm-svn: 232570
* Teach DataLayout to infer a plausible alignment for things even when nothing ↵Owen Anderson2015-03-081-3/+14
| | | | | | is specified by the user. llvm-svn: 231613
* Make DataLayout Non-Optional in the ModuleMehdi Amini2015-03-041-90/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: DataLayout keeps the string used for its creation. As a side effect it is no longer needed in the Module. This is "almost" NFC, the string is no longer canonicalized, you can't rely on two "equals" DataLayout having the same string returned by getStringRepresentation(). Get rid of DataLayoutPass: the DataLayout is in the Module The DataLayout is "per-module", let's enforce this by not duplicating it more than necessary. One more step toward non-optionality of the DataLayout in the module. Make DataLayout Non-Optional in the Module Module->getDataLayout() will never returns nullptr anymore. Reviewers: echristo Subscribers: resistor, llvm-commits, jholewinski Differential Revision: http://reviews.llvm.org/D7992 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231270
* Teach DataLayout that alignments on basic types must be powers of two.Owen Anderson2015-03-021-0/+4
| | | | | | Fixes assertion failures/crashes on bad datalayout specifications. llvm-svn: 230940
* Teach DataLayout that ABI alignments for non-aggregate types must be non-zero.Owen Anderson2015-03-021-0/+3
| | | | | | | This manifested as assertions and/or crashes in later phases of optimization, depending on the build configuration. llvm-svn: 230939
* Teach DataLayout that pointer ABI and preferred alignments are required to ↵Owen Anderson2015-03-021-0/+6
| | | | | | | | be powers of two. Previously this resulted in asserts and/or crashes (depending on build configuration) at various phases in the optimizer. llvm-svn: 230938
* Teach DataLayout that zero-byte pointer sizes don't make sense.Owen Anderson2015-03-021-0/+2
| | | | | | | | Previously this would result in assertion failures or simply crashes at various points in the optimizer when trying to create types of zero bit width. llvm-svn: 230936
* DataLayout: Validate that the pref alignment is at least the ABI alignDavid Majnemer2015-02-161-1/+4
| | | | llvm-svn: 229355
* DataLayout: Report when the datalayout type alignment/width is too largeDavid Majnemer2015-02-161-6/+11
| | | | llvm-svn: 229354
* DataLayout: Report when the preferred alignment is less than the ABIDavid Majnemer2015-02-111-0/+3
| | | | llvm-svn: 228819
* DataLayout: Provide nicer diagnostics for malformed stringsDavid Majnemer2014-12-101-2/+11
| | | | llvm-svn: 223911
* DataLayout: Be more verbose when diagnosing problems in pointer specsDavid Majnemer2014-12-101-3/+10
| | | | llvm-svn: 223903
* DataLayout: Move asserts over to report_fatal_errorDavid Majnemer2014-12-101-7/+10
| | | | | | | | As indicated by the tests, it is possible to feed the AsmParser an invalid datalayout string. We should verify the result of parsing this string regardless of whether or not we have assertions enabled. llvm-svn: 223898
* Switch the default DataLayout to be little endian, and make the variableChandler Carruth2014-10-201-5/+5
| | | | | | | | | be BigEndian so the default can continue to be zero-initialized. This is one of the prerequisites to making DataLayout a constant and always available part of every module. llvm-svn: 220193
* IR: Replace DataLayout::RoundUpAlignment with RoundUpToAlignmentDavid Majnemer2014-10-201-2/+2
| | | | | | No functional change intended, just cleaning up some code. llvm-svn: 220187
* Use cast<> instead of unchecked dyn_cast<>Matt Arsenault2014-09-181-1/+1
| | | | llvm-svn: 218085
* Add doInitialization/doFinalization to DataLayoutPass.Rafael Espindola2014-09-101-7/+11
| | | | | | | | | | | | | With this a DataLayoutPass can be reused for multiple modules. Once we have doInitialization/doFinalization, it doesn't seem necessary to pass a Module to the constructor. Overall this change seems in line with the idea of making DataLayout a required part of Module. With it the only way of having a DataLayout used is to add it to the Module. llvm-svn: 217548
* Revert "Introduce a string_ostream string builder facilty"Alp Toker2014-06-261-1/+2
| | | | | | Temporarily back out commits r211749, r211752 and r211754. llvm-svn: 211814
* Introduce a string_ostream string builder faciltyAlp Toker2014-06-261-2/+1
| | | | | | | | | | | | | | | | | | | | string_ostream is a safe and efficient string builder that combines opaque stack storage with a built-in ostream interface. small_string_ostream<bytes> additionally permits an explicit stack storage size other than the default 128 bytes to be provided. Beyond that, storage is transferred to the heap. This convenient class can be used in most places an std::string+raw_string_ostream pair or SmallString<>+raw_svector_ostream pair would previously have been used, in order to guarantee consistent access without byte truncation. The patch also converts much of LLVM to use the new facility. These changes include several probable bug fixes for truncated output, a programming error that's no longer possible with the new interface. llvm-svn: 211749
* Use pointer size function where only a pointer is expectedMatt Arsenault2014-04-231-1/+1
| | | | llvm-svn: 207023
OpenPOWER on IntegriCloud