summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/ABIInfo.h
Commit message (Collapse)AuthorAgeFilesLines
* Support __builtin_ms_va_list.Charles Davis2015-09-171-0/+6
| | | | | | | | | | | | | | | | | | Summary: This change adds support for `__builtin_ms_va_list`, a GCC extension for variadic `ms_abi` functions. The existing `__builtin_va_list` support is inadequate for this because `va_list` is defined differently in the Win64 ABI vs. the System V/AMD64 ABI. Depends on D1622. Reviewers: rsmith, rnk, rjmccall CC: cfe-commits Differential Revision: http://reviews.llvm.org/D1623 llvm-svn: 247941
* Compute and preserve alignment more faithfully in IR-generation.John McCall2015-09-081-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
* [MIPS] Re-land the change r238200 to fix extension of integer typesPetar Jovanovic2015-05-261-0/+2
| | | | | | | | Re-land the change r238200, but with modifications in the tests that should prevent new failures in some environments as reported with the original change on the mailing list. llvm-svn: 238253
* Revert r238200: "[MIPS] fix extension of integer types (function calls)"Hans Wennborg2015-05-261-2/+0
| | | | | | mips-unsigned-ext-var.c and mips-unsigned-extend.c fail in some builds. llvm-svn: 238237
* [MIPS] fix extension of integer types (function calls)Petar Jovanovic2015-05-261-0/+2
| | | | | | | | | | On MIPS unsigned int type should not be zero extended but sign-extended. Patch by Strahinja Petrovic. Differential Revision: http://reviews.llvm.org/D9198 llvm-svn: 238200
* Fix invalid calling convention used for libcalls on ARM.Anton Korobeynikov2014-12-021-1/+9
| | | | | | | | | | | | | | | | ARM ABI specifies that all the libcalls use soft FP ABI (even hard FP binaries). These days clang emits _mulsc3 / _muldc3 calls with default (C) calling convention which would be translated into AAPCS_VFP LLVM calling and thus the result of complex multiplication will be bogus. Introduce a way for a target to specify explicitly calling convention for libcalls. Right now this is temporary correctness fix. Ultimately, we'll end with intrinsic for complex multiplication and all calling convention decisions for libcalls will be put into backend. llvm-svn: 223123
* Fix ARM HVA classification of classes with non-virtual basesReid Kleckner2014-10-311-0/+9
| | | | | | | | | | | | | | | | Reuse the PPC64 HVA detection algorithm for ARM and AArch64. This is a nice code deduplication, since they are roughly identical. A few virtual method extension points are needed to understand how big an HVA can be and what element types it can have for a given architecture. Also make the record expansion code work in the presence of non-virtual bases. Reviewed By: uweigand, asl Differential Revision: http://reviews.llvm.org/D6045 llvm-svn: 220972
* Header guard canonicalization, clang part.Benjamin Kramer2014-08-131-2/+2
| | | | | | Modifications made by clang-tidy with minor tweaks. llvm-svn: 215557
* Sort all the #include lines with LLVM's utils/sort_includes.py whichChandler Carruth2014-01-071-1/+1
| | | | | | | encodes the canonical rules for LLVM's style. I noticed this had drifted quite a bit when cleaning up LLVM, so wanted to clean up Clang as well. llvm-svn: 198686
* Add CodeGenABITypes.h for use in LLDB.Mark Lacey2013-10-301-145/+0
| | | | | | | | | | | | | | | | | | CodeGenABITypes is a wrapper built on top of CodeGenModule that exposes some of the functionality of CodeGenTypes (held by CodeGenModule), specifically methods that determine the LLVM types appropriate for function argument and return values. I addition to CodeGenABITypes.h, CGFunctionInfo.h is introduced, and the definitions of ABIArgInfo, RequiredArgs, and CGFunctionInfo are moved into this new header from the private headers ABIInfo.h and CGCall.h. Exposing this functionality is one part of making it possible for LLDB to determine the actual ABI locations of function arguments and return values, making it possible for it to determine this for any supported target without hard-coding ABI knowledge in the LLDB code. llvm-svn: 193717
* Pass CGCXXABIs around directly.Mark Lacey2013-10-061-0/+2
| | | | | | | | | | In functions that only need to use the CGCXXABI member of a CodeGenTypes class, pass that reference around directly rather than a reference to a CodeGenTypes class. This makes the actual dependence on CGCXXABI clear at the call sites. llvm-svn: 192052
* Standardize accesses to the TargetInfo in IR-gen.John McCall2013-04-161-0/+2
| | | | | | Patch by Stephen Lin! llvm-svn: 179638
* Use the actual ABI-determined C calling convention for runtimeJohn McCall2013-02-281-1/+12
| | | | | | | | | | | | | | | | | | | | | | calls and declarations. LLVM has a default CC determined by the target triple. This is not always the actual default CC for the ABI we've been asked to target, and so we sometimes find ourselves annotating all user functions with an explicit calling convention. Since these calling conventions usually agree for the simple set of argument types passed to most runtime functions, using the LLVM-default CC in principle has no effect. However, the LLVM optimizer goes into histrionics if it sees this kind of formal CC mismatch, since it has no concept of CC compatibility. Therefore, if this module happens to define the "runtime" function, or got LTO'ed with such a definition, we can miscompile; so it's quite important to get this right. Defining runtime functions locally is quite common in embedded applications. llvm-svn: 176286
* Add support for AArch64 target.Tim Northover2013-01-311-2/+4
| | | | | | | | | | | | | In cooperation with the LLVM patch, this should implement all scalar front-end parts of the C and C++ ABIs for AArch64. This patch excludes the NEON support also reviewed due to an outbreak of batshit insanity in our legal department. That will be committed soon bringing the changes to precisely what has been approved. Further reviews would be gratefully received. llvm-svn: 174055
* Rewrite #includes for llvm/Foo.h to llvm/IR/Foo.h as appropriate toChandler Carruth2013-01-021-1/+1
| | | | | | | | reflect the migration in r171366. Re-sort the #include lines to reflect the new paths. llvm-svn: 171369
* Add padding inreg registers to cause llvm to skip ecx when needed withRafael Espindola2012-10-241-11/+21
| | | | | | the x86_fastcallcc calling convention. llvm-svn: 166538
* Fix handling of the regparm attribute in the presence of classes with copyRafael Espindola2012-10-191-1/+1
| | | | | | | | | | | | | constructors. When I first moved regparm support to TargetInfo.cpp I tried to isolate it in classifyArgumentTypeWithReg, but it is actually a lot easier to flip the code around and check for regparm at the end of the decision tree. Without this refactoring classifyArgumentTypeWithReg would have to duplicate the logic about when to use non-byval indirect arguments. llvm-svn: 166266
* Move TargetData to DataLayout.Micah Villmow2012-10-081-2/+2
| | | | llvm-svn: 165395
* Handle functions with struct arguments or return types and the regparmRafael Espindola2012-07-311-7/+23
| | | | | | | | | | | | | | attribute. It is a variation of the x86_64 ABI: * A struct returned indirectly uses the first register argument to pass the pointer. * Floats, Doubles and structs containing only one of them are not passed in registers. * Other structs are split into registers if they fit on the remaining ones. Otherwise they are passed in memory. * When a struct doesn't fit it still consumes the registers. llvm-svn: 161022
* ABIArgInfo's constructor is private and only used by the static get* methods.Rafael Espindola2012-07-241-6/+6
| | | | | | No need to abuse default arguments. llvm-svn: 160684
* Add field PaddingType to ABIArgInfo which specifies the type of padding thatAkira Hatanaka2012-01-071-6/+15
| | | | | | | | is inserted before the real argument. Padding is needed to ensure the backend reads from or writes to the correct argument slots when the original alignment of a byval structure is unavailable due to flattening. llvm-svn: 147699
* clang side to match the LLVM IR type system rewrite patch.Chris Lattner2011-07-091-6/+6
| | | | llvm-svn: 134831
* Fix Whitespace.Michael J. Spencer2010-10-191-7/+7
| | | | llvm-svn: 116798
* IRgen/ABI: Add support for realigning structures which are passed by indirectDaniel Dunbar2010-09-161-6/+13
| | | | | | reference. llvm-svn: 114114
* fix PR5179 and correctly fix PR5831 to not miscompile.Chris Lattner2010-07-301-23/+32
| | | | | | | | | | | | | | | | | | | | The X86-64 ABI code didn't handle the case when a struct would get classified and turn up as "NoClass INTEGER" for example. This is perfectly possible when the first slot is all padding (e.g. due to empty base classes). In this situation, the first 8-byte doesn't take a register at all, only the second 8-byte does. This fixes this by enhancing the x86-64 abi stuff to allow and handle this case, reverts the broken fix for PR5831, and enhances the target independent stuff to be able to handle an argument value in registers being accessed at an offset from the memory value. This is the last x86-64 calling convention related miscompile that I'm aware of. llvm-svn: 109848
* move the last hunk of getCoerceResult into the placeChris Lattner2010-07-291-2/+2
| | | | | | that needs it and remove getCoerceResult. llvm-svn: 109807
* fix a builder, why didn't clang++ catch this?Chris Lattner2010-07-291-1/+1
| | | | llvm-svn: 109735
* Kill off the 'coerce' ABI passing form. Now 'direct' and 'extend' alwaysChris Lattner2010-07-291-16/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | have a "coerce to" type which often matches the default lowering of Clang type to LLVM IR type, but the coerce case can be handled by making them not be the same. This simplifies things and fixes issues where X86-64 abi lowering would return coerce after making preferred types exactly match up. This caused us to compile: typedef float v4f32 __attribute__((__vector_size__(16))); v4f32 foo(v4f32 X) { return X+X; } into this code at -O0: define <4 x float> @foo(<4 x float> %X.coerce) nounwind { entry: %retval = alloca <4 x float>, align 16 ; <<4 x float>*> [#uses=2] %coerce = alloca <4 x float>, align 16 ; <<4 x float>*> [#uses=2] %X.addr = alloca <4 x float>, align 16 ; <<4 x float>*> [#uses=3] store <4 x float> %X.coerce, <4 x float>* %coerce %X = load <4 x float>* %coerce ; <<4 x float>> [#uses=1] store <4 x float> %X, <4 x float>* %X.addr %tmp = load <4 x float>* %X.addr ; <<4 x float>> [#uses=1] %tmp1 = load <4 x float>* %X.addr ; <<4 x float>> [#uses=1] %add = fadd <4 x float> %tmp, %tmp1 ; <<4 x float>> [#uses=1] store <4 x float> %add, <4 x float>* %retval %0 = load <4 x float>* %retval ; <<4 x float>> [#uses=1] ret <4 x float> %0 } Now we get: define <4 x float> @foo(<4 x float> %X) nounwind { entry: %X.addr = alloca <4 x float>, align 16 ; <<4 x float>*> [#uses=3] store <4 x float> %X, <4 x float>* %X.addr %tmp = load <4 x float>* %X.addr ; <<4 x float>> [#uses=1] %tmp1 = load <4 x float>* %X.addr ; <<4 x float>> [#uses=1] %add = fadd <4 x float> %tmp, %tmp1 ; <<4 x float>> [#uses=1] ret <4 x float> %add } This implements rdar://8248065 llvm-svn: 109733
* dissolve some more complexity: make the x86-64 abi lowering codeChris Lattner2010-07-291-5/+1
| | | | | | | compute its own preferred types instead of having CGT compute them then pass them (circuituously) down into ABIInfo. llvm-svn: 109726
* now that ABIInfo depends on CGT, it has trivial access to suchChris Lattner2010-07-291-2/+0
| | | | | | | things as TargetData, ASTContext, LLVMContext etc. Stop passing them through so many APIs. llvm-svn: 109723
* cave in to reality and make ABIInfo depend on CodeGenTypes.Chris Lattner2010-07-291-6/+14
| | | | | | This will simplify a bunch of code, coming up next. llvm-svn: 109722
* tidy upChris Lattner2010-07-281-5/+4
| | | | llvm-svn: 109699
* change ABIArgInfo to hold its llvm type with PATypeHolder so thatChris Lattner2010-06-291-4/+2
| | | | | | | it doesn't dangle as types get refined. This fixes Shootout-C++/lists1 and probably also PR7522. llvm-svn: 107196
* Pass the LLVM IR version of argument types down into computeInfo.Chris Lattner2010-06-291-1/+5
| | | | | | | | | This is somewhat annoying to do this at this level, but it avoids having ABIInfo know depend on CodeGenTypes for a hint. Nothing is using this yet, so no functionality change. llvm-svn: 107111
* x86-64 ABI: If a type is a C++ record with either a non-trivial destructor ↵Anders Carlsson2009-09-161-6/+12
| | | | | | or a non-trivial copy constructor, it should be passed in a pointer. Daniel, plz review. llvm-svn: 82050
* LLVMContext is a class now.Benjamin Kramer2009-08-111-1/+1
| | | | llvm-svn: 78691
* Update for LLVM API change.Owen Anderson2009-08-051-1/+1
| | | | llvm-svn: 78259
* Update for LLVM API change, and contextify a bunch of related stuff.Owen Anderson2009-07-141-1/+3
| | | | llvm-svn: 75705
* Add new ABIArgInfo kind: Extend. This allows target to implement its own ↵Anton Korobeynikov2009-06-061-0/+7
| | | | | | | | | argument zero/sign extension logic (consider, e.g. target has only 64 bit registers and thus i32's should be extended as well). llvm-svn: 72998
* Factor out TargetABIInfo stuff into separate file. No functionality change.Anton Korobeynikov2009-06-051-14/+19
| | | | llvm-svn: 72962
* Pull CodeGenFunction::EmitVAArg into target specific ABIInfo classes.Daniel Dunbar2009-02-101-0/+11
| | | | | | - Missed this file. llvm-svn: 64238
* Merge ABIInfo StructRet/ByVal into Indirect. Daniel Dunbar2009-02-051-20/+11
| | | | | | - No (intended) functionality change, the semantic changes are to come. llvm-svn: 63850
* Initialize alignment field for ByVal ABIInfo correctly.Daniel Dunbar2009-02-051-1/+1
| | | | llvm-svn: 63809
* Add ABIArgInfo::dump()Daniel Dunbar2009-02-041-0/+2
| | | | llvm-svn: 63794
* Change ABIInfo to compute information for a full signature at a timeDaniel Dunbar2009-02-031-6/+11
| | | | | | (the main point of this restructing). llvm-svn: 63619
* Remove ABIArgInfo::Default kind, ABI is now responsible for specifyingDaniel Dunbar2009-02-031-8/+2
| | | | | | acceptable kind with more precise semantics. llvm-svn: 63617
* Add ABIArgInfo::Direct kind, which passes arguments using whatever theDaniel Dunbar2009-02-031-0/+8
| | | | | | | native IRgen type is. This is like Default, but without any extra semantics (like automatic tweaking of structures or void). llvm-svn: 63615
* Move ABIArgInfo into CGFunctionInfo, computed on creation.Daniel Dunbar2009-02-031-0/+6
| | | | | | - Still have to convert some consumers over. llvm-svn: 63610
* Move ABIInfo/ABIArgInfo classes into ABIInfo.hDaniel Dunbar2009-02-031-0/+116
llvm-svn: 63586
OpenPOWER on IntegriCloud