aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/IR/DataLayout.cpp
AgeCommit message (Collapse)AuthorFilesLines
2019-03-06Revert "[IR][ARM] Add function pointer alignment to datalayout"Mitch Phillips1-20/+0
This reverts commit 2391bfca97290181ae65796ea6da135d1b6d037b. This reverts rL355522 (https://reviews.llvm.org/D57335). Kills buildbots that use '-Werror' with the following error: /var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm/lib/IR/Value.cpp:657:7: error: default label in switch which covers all enumeration values [-Werror,-Wcovered-switch-default] See buildbots http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/30200/steps/check-llvm%20asan/logs/stdio for more information. llvm-svn: 355537
2019-03-06[IR][ARM] Add function pointer alignment to datalayoutMichael Platings1-0/+20
Use this feature to fix a bug on ARM where 4 byte alignment is incorrectly assumed. Differential Revision: https://reviews.llvm.org/D57335 llvm-svn: 355522
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-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
2019-01-02[BasicAA] Support arbitrary pointer sizes (and fix an overflow bug)Hal Finkel1-0/+8
Motivated by the discussion in D38499, this patch updates BasicAA to support arbitrary pointer sizes by switching most remaining non-APInt calculations to use APInt. The size of these APInts is set to the maximum pointer size (maximum over all address spaces described by the data layout string). Most of this translation is straightforward, but this patch contains a fix for a bug that revealed itself during this translation process. In order for test/Analysis/BasicAA/gep-and-alias.ll to pass, which is run with 32-bit pointers, the intermediate calculations must be performed using 64-bit integers. This is because, as noted in the patch, when GetLinearExpression decomposes an expression into C1*V+C2, and we then multiply this by Scale, and distribute, to get (C1*Scale)*V + C2*Scale, it can be the case that, even through C1*V+C2 does not overflow for relevant values of V, (C2*Scale) can overflow. If this happens, later logic will draw invalid conclusions from the (base) offset value. Thus, when initially applying the APInt conversion, because the maximum pointer size in this test is 32 bits, it started failing. Suspicious, I created a 64-bit version of this test (included here), and that failed (miscompiled) on trunk for a similar reason (the multiplication can overflow). After fixing this overflow bug, the first test case (at least) in Analysis/BasicAA/q.bad.ll started failing. This is also a 32-bit test, and was relying on having 64-bit intermediate values to have BasicAA return an accurate result. In order to fix this problem, and because I believe that it is not uncommon to use i64 indexing expressions in 32-bit code (especially portable code using int64_t), it seems reasonable to always use at least 64-bit integers. In this way, we won't regress our analysis capabilities (and there's a command-line option added, so experimenting with this should be easy). As pointed out by Eli during the review, there are other potential overflow conditions that this patch does not address. Fixing those is left to follow-up work. Patch by me with contributions from Michael Ferguson (mferguson@cray.com). Differential Revision: https://reviews.llvm.org/D38662 llvm-svn: 350220
2018-08-29[NFC] Make getPreferredAlignment honor section markings.Eli Friedman1-1/+15
This should more accurately reflect what the AsmPrinter will actually do. This is NFC, as far as I can tell; all the places that might be affected already have an extra check to avoid using the result of getPreferredAlignment in this situation. Differential Revision: https://reviews.llvm.org/D51377 llvm-svn: 340999
2018-06-09Use uniform mechanism for OOM errors handlingSerge Pavlov1-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
2018-05-30Revert commit 333506Serge Pavlov1-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
2018-05-30Use uniform mechanism for OOM errors handlingSerge Pavlov1-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
2018-05-29Reverted commits 333390, 333391 and 333394Serge Pavlov1-2/+4
Build of shared library LLVMDemangle.so fails due to dependency problem. llvm-svn: 333395
2018-05-29Use uniform mechanism for OOM errors handlingSerge Pavlov1-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
2018-02-19Add default address space for functions to the data layout (1/3)Dylan McKay1-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
2018-02-14Adding a width of the GEP index to the Data Layout.Elena Demikhovsky1-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
2017-07-20Support, IR, ADT: Check nullptr after allocation with malloc/realloc or callocMatthias Braun1-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
2017-06-06Sort the remaining #include lines in include/... and lib/....Chandler Carruth1-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
2017-05-22[DataLayout] Add llvm_unreachable to the default of a nested switch ↵Craig Topper1-1/+1
statement that covers all values given to it by the outer switch. NFC llvm-svn: 303571
2017-05-05[IR] Fix some Clang-tidy modernize-use-using warnings; other minor fixes (NFC).Eugene Zelenko1-12/+15
llvm-svn: 302310
2017-04-19[DataLayout] Removed default value from a variable that isn't used without ↵Craig Topper1-3/+2
being overwritten. Make variable an enum instead of an int to avoid a cast later. NFC llvm-svn: 300634
2017-04-17[IR] Implement DataLayout::getPointerTypeSizeInBits using ↵Craig Topper1-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
2017-04-10Allow DataLayout to specify addrspace for allocas.Matt Arsenault1-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
2017-03-23[IR] Use a binary search in DataLayout::getAlignmentInfoCraig Topper1-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
2017-03-21[IR] Remove validAlignment and validPointer methods DataLayout as they ↵Craig Topper1-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
2016-12-02IR: Change the gep_type_iterator API to avoid always exposing the "current" ↵Peter Collingbourne1-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
2016-11-11[IR/DataLayout] Simplify the code using PowerOf2Ceil. NFCI.Davide Italiano1-6/+2
llvm-svn: 286554
2016-07-28[IR] Introduce a non-integral pointer typeSanjoy Das1-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
2016-07-13[IR] Make getIndexedOffsetInType return a signed resultDavid Majnemer1-5/+5
A GEPed offset can go negative, the result of getIndexedOffsetInType should according be a signed type. llvm-svn: 275246
2016-05-13Rename getLargestLegalIntTypeSize to getLargestLegalIntTypeSizeInBits(). NFC.Jun Bum Lim1-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
2016-01-22Replace Type::getInt32Ty() and comparison by isIntegerTy(32). NFC.Manuel Jacob1-3/+1
llvm-svn: 258480
2016-01-22[opaque pointer types] [NFC] DataLayout::getIndexedOffset: take source ↵Eduard Burtescu1-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
2016-01-22[opaque pointer types] [NFC] gep_type_{begin,end} now take source element ↵Eduard Burtescu1-1/+4
type and address space. Reviewers: mjacob, dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16436 llvm-svn: 258474
2016-01-16GlobalValue: use getValueType() instead of getType()->getPointerElementType().Manuel Jacob1-1/+1
Reviewers: mjacob Subscribers: jholewinski, arsenm, dsanders, dblaikie Patch by Eduard Burtescu. Differential Revision: http://reviews.llvm.org/D16260 llvm-svn: 257999
2016-01-14Update to use new name alignTo().Rui Ueyama1-2/+2
llvm-svn: 257804
2015-12-15Instcombine: destructor loads of structs that do not contains paddingMehdi Amini1-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
2015-07-27Revert "Add const to a bunch of Type* in DataLayout. NFC."Pete Cooper1-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
2015-07-24Add const to a bunch of Type* in DataLayout. NFC.Pete Cooper1-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
2015-07-21fix formatting; NFCSanjay Patel1-2/+2
llvm-svn: 242796
2015-03-17COFF: Let globals with private linkage reside in their own sectionDavid Majnemer1-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
2015-03-08Teach DataLayout to infer a plausible alignment for things even when nothing ↵Owen Anderson1-3/+14
is specified by the user. llvm-svn: 231613
2015-03-04Make DataLayout Non-Optional in the ModuleMehdi Amini1-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
2015-03-02Teach DataLayout that alignments on basic types must be powers of two.Owen Anderson1-0/+4
Fixes assertion failures/crashes on bad datalayout specifications. llvm-svn: 230940
2015-03-02Teach DataLayout that ABI alignments for non-aggregate types must be non-zero.Owen Anderson1-0/+3
This manifested as assertions and/or crashes in later phases of optimization, depending on the build configuration. llvm-svn: 230939
2015-03-02Teach DataLayout that pointer ABI and preferred alignments are required to ↵Owen Anderson1-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
2015-03-02Teach DataLayout that zero-byte pointer sizes don't make sense.Owen Anderson1-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
2015-02-16DataLayout: Validate that the pref alignment is at least the ABI alignDavid Majnemer1-1/+4
llvm-svn: 229355
2015-02-16DataLayout: Report when the datalayout type alignment/width is too largeDavid Majnemer1-6/+11
llvm-svn: 229354
2015-02-11DataLayout: Report when the preferred alignment is less than the ABIDavid Majnemer1-0/+3
llvm-svn: 228819
2014-12-10DataLayout: Provide nicer diagnostics for malformed stringsDavid Majnemer1-2/+11
llvm-svn: 223911
2014-12-10DataLayout: Be more verbose when diagnosing problems in pointer specsDavid Majnemer1-3/+10
llvm-svn: 223903
2014-12-10DataLayout: Move asserts over to report_fatal_errorDavid Majnemer1-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
2014-10-20Switch the default DataLayout to be little endian, and make the variableChandler Carruth1-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
2014-10-20IR: Replace DataLayout::RoundUpAlignment with RoundUpToAlignmentDavid Majnemer1-2/+2
No functional change intended, just cleaning up some code. llvm-svn: 220187
generated by cgit v1.1 at 2025-09-29 05:50:29 +0000