summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGExprConstant.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix unused variable warnings. NFCI.Simon Pilgrim2016-12-091-3/+3
| | | | llvm-svn: 289285
* Add support for non-zero null pointer for C and OpenCLYaxun Liu2016-12-091-24/+38
| | | | | | | | | | | | | | | | | | In amdgcn target, null pointers in global, constant, and generic address space take value 0 but null pointers in private and local address space take value -1. Currently LLVM assumes all null pointers take value 0, which results in incorrectly translated IR. To workaround this issue, instead of emit null pointers in local and private address space, a null pointer in generic address space is emitted and casted to local and private address space. Tentative definition of global variables with non-zero initializer will have weak linkage instead of common linkage since common linkage requires zero initializer and does not have explicit section to hold the non-zero value. Virtual member functions getNullPointer and performAddrSpaceCast are added to TargetCodeGenInfo which by default returns ConstantPointerNull and emitting addrspacecast instruction. A virtual member function getNullPointerValue is added to TargetInfo which by default returns 0. Each target can override these virtual functions to get target specific null pointer and the null pointer value for specific address space, and perform specific translations for addrspacecast. Wrapper functions getNullPointer is added to CodegenModule and getTargetNullPointerValue is added to ASTContext to facilitate getting the target specific null pointers and their values. This change has no effect on other targets except amdgcn target. Other targets can provide support of non-zero null pointer in a similar way. This change only provides support for non-zero null pointer for C and OpenCL. Supporting for other languages will be added later incrementally. Differential Revision: https://reviews.llvm.org/D26196 llvm-svn: 289252
* [c++17] P0135R1: Guaranteed copy elision.Richard Smith2016-12-061-3/+3
| | | | | | | | When an object of class type is initialized from a prvalue of the same type (ignoring cv qualifications), use the prvalue to initialize the object directly instead of inserting a redundant elidable call to a copy constructor. llvm-svn: 288866
* [CodeGen] Use StringRef. NFC.George Burgess IV2016-11-031-2/+2
| | | | | | | | Looks like CurFn's name outlives FunctionName, so we can just pass StringRefs around rather than going from a StringRef to a std::string to a const char* to a StringRef. llvm-svn: 285873
* [CodeGen] Fix an assert in EmitNullConstant.Akira Hatanaka2016-09-131-1/+2
| | | | | | | | | | | | | | | r235815 changed CGRecordLowering::accumulateBases to ignore non-virtual bases of size 0, which prevented adding those non-virtual bases to CGRecordLayout's NonVirtualBases. This caused clang to assert when CGRecordLayout::getNonVirtualBaseLLVMFieldNo was called in EmitNullConstant. This commit fixes the bug by ignoring zero-sized non-virtual bases in EmitNullConstant. rdar://problem/28100139 Differential Revision: https://reviews.llvm.org/D24312 llvm-svn: 281405
* [OpenCL] Generate opaque type for sampler_t and function call for the ↵Yaxun Liu2016-07-281-0/+3
| | | | | | | | | | | | | | | | initializer Currently Clang use int32 to represent sampler_t, which have been a source of issue for some backends, because in some backends sampler_t cannot be represented by int32. They have to depend on kernel argument metadata and use IPA to find the sampler arguments and global variables and transform them to target specific sampler type. This patch uses opaque pointer type opencl.sampler_t* for sampler_t. For each use of file-scope sampler variable, it generates a function call of __translate_sampler_initializer. For each initialization of function-scope sampler variable, it generates a function call of __translate_sampler_initializer. Each builtin library can implement its own __translate_sampler_initializer(). Since the real sampler type tends to be architecture dependent, allowing it to be initialized by a library function simplifies backend design. A typical implementation of __translate_sampler_initializer could be a table lookup of real sampler literal values. Since its argument is always a literal, the returned pointer is known at compile time and easily optimized to finally become some literal values directly put into image read instructions. This patch is partially based on Alexey Sotkin's work in Khronos Clang (https://github.com/KhronosGroup/SPIR/commit/3d4eec61623502fc306e8c67c9868be2b136e42b). Differential Revision: https://reviews.llvm.org/D21567 llvm-svn: 277024
* Re-commit "[Temporary] Add an ExprWithCleanups for each C++ ↵Tim Shen2016-06-211-0/+6
| | | | | | | | | | MaterializeTemporaryExpr." Since D21243 fixes relative clang-tidy tests. This reverts commit a71d9fbd41e99def9159af2b01ef6509394eaeed. llvm-svn: 273312
* [CodeGen] Use pointer-sized integers for ptrtoint sourcesDavid Majnemer2016-06-171-1/+7
| | | | | | | | | | | | | | | | | Given something like: void *v = (void *)100; We need to synthesize a ptrtoint operation from 100. During constant emission, we choose i64 as the type for our constant because it guaranteed not to drop any bits from our CharUnits representation of the value. However, this is suboptimal for 32-bit targets: LLVM passes like GlobalOpt will get confused by these sorts of casts resulting in pessimization. Instead, make sure the ptrtoint operand has a pointer-sized integer type. llvm-svn: 273020
* Revert "[Temporary] Add an ExprWithCleanups for each C++ ↵Tim Shen2016-06-091-6/+0
| | | | | | | | | MaterializeTemporaryExpr." This reverts r272296, since there are clang-tidy failures that appear to be caused by this change. llvm-svn: 272310
* [Temporary] Add an ExprWithCleanups for each C++ MaterializeTemporaryExpr.Tim Shen2016-06-091-0/+6
| | | | | | | | | | | These ExprWithCleanups are added for holding a RunCleanupsScope not for destructor calls; rather, they are for lifetime marks. This requires ExprWithCleanups to keep a bit to indicate whether it have cleanups with side effects (e.g. dtor calls). Differential Revision: http://reviews.llvm.org/D20498 llvm-svn: 272296
* P0017R1: In C++1z, an aggregate class can have (public non-virtual) base ↵Richard Smith2016-03-081-1/+15
| | | | | | classes; these are initialized as if they were data members. llvm-svn: 262963
* Update for LLVM function name change.Rui Ueyama2016-01-141-12/+11
| | | | llvm-svn: 257802
* [Bugfix] Fix ICE on constexpr vector splat.George Burgess IV2016-01-131-0/+1
| | | | | | | | | | | | | In {CG,}ExprConstant.cpp, we weren't treating vector splats properly. This patch makes us treat splats more properly. Additionally, this patch adds a new cast kind which allows a bool->int cast to result in -1 or 0, instead of 1 or 0 (for true and false, respectively), so we can sanely model OpenCL bool->int casts in the AST. Differential Revision: http://reviews.llvm.org/D14877 llvm-svn: 257559
* Clean ExprConstant/CGExprConstant up a bit. NFC.George Burgess IV2015-12-111-5/+7
| | | | llvm-svn: 255314
* PR25368: Replace workaround for build failure with modules enabled with a fixRichard Smith2015-11-051-1/+1
| | | | | | | | | | | for the root cause. The 'using llvm::isa;' declaration in Basic/LLVM.h only pulls the declarations of llvm::isa that were declared prior to it into namespace clang. In a modules build, this is a hermetic set of just the declarations from LLVM. In a non-modules build, we happened to also pull the declaration from lib/CodeGen/Address.h into namespace clang, which made the code in question accidentally compile. llvm-svn: 252211
* CGExprConstant.cpp: Appease Modules.NAKAMURA Takumi2015-10-301-1/+1
| | | | llvm-svn: 251713
* [DEBUG INFO] Emit debug info for type used in explicit cast only.Alexey Bataev2015-10-201-0/+2
| | | | | | | Currently debug info for types used in explicit cast only is not emitted. It happened after a patch for better alignment handling. This patch fixes this bug. Differential Revision: http://reviews.llvm.org/D13582 llvm-svn: 250795
* Compute and preserve alignment more faithfully in IR-generation.John McCall2015-09-081-19/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CodeGen] Rename EmitMemberPointer to EmitMemberFunctionPointerDavid Majnemer2015-06-231-1/+1
| | | | llvm-svn: 240382
* Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").Alexander Kornienko2015-06-221-1/+1
| | | | llvm-svn: 240353
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-221-1/+1
| | | | | | | | | | | | The patch is generated using this command: $ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ work/llvm/tools/clang To reduce churn, not touching namespaces spanning less than 10 lines. llvm-svn: 240270
* Implementing C99 partial re-initialization behavior (DR-253)Yunzhong Gao2015-06-101-0/+156
| | | | | | | | | | | | | | | | | | | | | | | | | Based on previous discussion on the mailing list, clang currently lacks support for C99 partial re-initialization behavior: Reference: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-April/029188.html Reference: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_253.htm This patch attempts to fix this problem. Given the following code snippet, struct P1 { char x[6]; }; struct LP1 { struct P1 p1; }; struct LP1 l = { .p1 = { "foo" }, .p1.x[2] = 'x' }; // this example is adapted from the example for "struct fred x[]" in DR-253; // currently clang produces in l: { "\0\0x" }, // whereas gcc 4.8 produces { "fox" }; // with this fix, clang will also produce: { "fox" }; Differential Review: http://reviews.llvm.org/D5789 llvm-svn: 239446
* [CodeGen] Indirect fields can initialize a unionDavid Majnemer2015-05-301-2/+8
| | | | | | | | The first named data member is the field used to default initialize the union. An IndirectFieldDecl can introduce the first named data member of a union. llvm-svn: 238649
* [CodeGen] Handle flexible array members containing pointers to membersDavid Majnemer2015-05-261-4/+0
| | | | | | | | | | Types can be classified as being zero-initializable or non-zero-initializable. We used to classify array types by giving them the classification of their base element type. However, incomplete array types are never initialized directly and thus are always zero-initializable. llvm-svn: 238256
* Replace getPointeeType()->isFunctionType with isMemberDataPointerTypeDavid Majnemer2015-04-241-2/+1
| | | | llvm-svn: 235682
* [opaque pointer type] Update for GEP API changes in LLVMDavid Blaikie2015-04-021-1/+1
| | | | | | | | | | Now the GEP constant utility functions require the type to be explicitly passed (since eventually the pointer type will be opaque and not convey the required type information). For now callers can still pass nullptr (though none were needed here in Clang, which is nice) if convenienc/necessary, but eventually that will be disallowed as well. llvm-svn: 233937
* CodeGen: Correctly initialize bitfields with non-constant initializersDavid Majnemer2015-03-141-3/+8
| | | | | | | | It is possible to construct an initializer for a bitfield which is not constant. Instead of emitting code to initialize the field before the execution of main, clang would crash. llvm-svn: 232285
* CodeGen: Optimize emssion of zeroinitialzied arraysDavid Majnemer2014-12-281-12/+24
| | | | | | | | | Create an ConstantAggregateZero upfront if we see that it is viable. This saves us from having to manually push_back each and every initializer and then looping back over them to determine if they are 'null'. llvm-svn: 224908
* CodeGen: Compound literals with funny types shouldn't crashDavid Majnemer2014-12-141-1/+2
| | | | | | | | | | | | | | | | | CodeGen assumed that a compound literal with array type should have a corresponding LLVM IR array type. We had two bugs in this area: - Zero sized arrays in compound literals would lead to the creation of an opaque type. This is unnecessary, we should just create an array type with a bound of zero. - Funny record types (like unions) lead to exotic IR types for compound literals. In this case, CodeGen must be prepared to deal with the possibility that it might not have an array IR type. This fixes PR21912. llvm-svn: 224219
* Use nullptr to silence -Wsentinel when self-hosting on WindowsReid Kleckner2014-12-011-2/+2
| | | | | | | | | | | Richard rejected my Sema change to interpret an integer literal zero in a varargs context as a null pointer, so -Wsentinel sees an integer literal zero and fires off a warning. Only CodeGen currently knows that it promotes integer literal zeroes in this context to pointer size on Windows. I didn't want to teach -Wsentinel about that compatibility hack. Therefore, I'm migrating to C++11 nullptr. llvm-svn: 223079
* CodeGen: ConstStructBuilder must verify packed constraints after paddingDavid Majnemer2014-10-191-14/+30
| | | | | | | | | | | | | | | | | | This reverts commit r220169 which reverted r220153. However, it also contains additional changes: - We may need to add padding *after* we've packed the struct. This occurs when the aligned next field offset is greater than the new field's offset. When this occurs, we make the struct packed. *However*, once packed the next field offset might be less than the new feild's offset. It is in this case that we might further pad the struct. - We would pad structs which were perfectly sized! This behavior is immensely old. This behavior came from blindly subtracting NextFieldOffsetInChars from RecordSize. This doesn't take into account the fact that the struct might have a greater overall alignment than the last field. llvm-svn: 220175
* Revert r220153: "CodeGen: ConstStructBuilder must verify packed constraints ↵Chandler Carruth2014-10-191-10/+9
| | | | | | | | | | after padding" This commit caused two tests in LNT to regress. I'm able to reproduce on any platform and will send reproduction steps to the original commit log. This should restore the LNT bots that have been failing. llvm-svn: 220169
* CodeGen: ConstStructBuilder must verify packed constraints after paddingDavid Majnemer2014-10-191-9/+10
| | | | | | | | | | | | Before, ConstStructBuilder::AppendBytes would check packed constraints prior to padding being added before the field's offset. However, adding this padding might force our struct to be packed. Because we wouldn't check *after* adding padding, ConstStructBuilder would be in an inconsistent state leading to a crash. This fixes PR21300. llvm-svn: 220153
* CodeGen: Kill FillInNullDataMemberPointersDavid Majnemer2014-10-171-106/+3
| | | | | | | It exists to handle the case where base subobjects are character arrays. This never happens. llvm-svn: 220006
* Fix IRGen for referencing a static local before emitting its declReid Kleckner2014-10-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously CodeGen assumed that static locals were emitted before they could be accessed, which is true for automatic storage duration locals. However, it is possible to have CodeGen emit a nested function that uses a static local before emitting the function that defines the static local, breaking that assumption. Fix it by creating the static local upon access and ensuring that the deferred function body gets emitted. We may not be able to emit the initializer properly from outside the function body, so don't try. Fixes PR18020. See also previous attempts to fix static locals in PR6769 and PR7101. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D4787 llvm-svn: 219265
* Allow __fp16 as a function arg or return type for AArch64Oliver Stannard2014-08-271-1/+2
| | | | | | | | | | | ACLE 2.0 allows __fp16 to be used as a function argument or return type. This enables this for AArch64. This also fixes an existing bug that causes clang to not allow homogeneous floating-point aggregates with a base type of __fp16. This is valid for AAPCS64, but not for AAPCS-VFP. llvm-svn: 216558
* PR18097: Support initializing an _Atomic(T) from an object of C++ class type TRichard Smith2014-07-311-0/+19
| | | | | | | or a class derived from T. We already supported this when initializing _Atomic(T) from T for most (and maybe all) other reasonable values of T. llvm-svn: 214390
* [C++11] Use 'nullptr'. CodeGen edition.Craig Topper2014-05-211-20/+20
| | | | llvm-svn: 209272
* Objective-C [IRGen]. Fixes a crash in IRGen involving use ofFariborz Jahanian2014-04-231-1/+4
| | | | | | | 'typeof' to extract type of an @encode expression used in an initializer. // rdar://16655340 llvm-svn: 207004
* Bug 18567: Fix constantexpr pointer casts with address spaces.Matt Arsenault2014-04-171-1/+3
| | | | | | | Getting a pointer into a struct at a non-zero offset would try to use the default address space. llvm-svn: 206478
* [C++11] Replacing CXXRecordDecl iterators vbases_begin() and vbases_end() ↵Aaron Ballman2014-03-131-3/+2
| | | | | | with iterator_range vbases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203808
* [C++11] Replacing CXXRecordDecl iterators bases_begin() and bases_end() with ↵Aaron Ballman2014-03-131-9/+7
| | | | | | iterator_range bases(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203803
* [C++11] Replacing RecordDecl iterators field_begin() and field_end() with ↵Aaron Ballman2014-03-081-8/+5
| | | | | | iterator_range fields(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203355
* Rename isBuiltinCall() to getBuiltinCallee()Alp Toker2013-12-281-1/+1
| | | | | | | | This better describes what the function does. Cleanup only. llvm-svn: 198127
* Add front-end infrastructure now address space casts are in LLVM IR.David Tweed2013-12-111-2/+5
| | | | | | | | | | With the introduction of explicit address space casts into LLVM, there's a need to provide a new cast kind the front-end can create for C/OpenCL/CUDA and code to produce address space casts from those kinds when appropriate. Patch by Michele Scandale! llvm-svn: 197036
* Abstract out the emission of vtables, add basic support for vtable emission ↵Timur Iskhodzhanov2013-09-271-31/+10
| | | | | | | | when using -cxx-abi microsoft Reviewed at http://llvm-reviews.chandlerc.com/D1532 llvm-svn: 191523
* AST: Handle qualified array types in typeid() expressionsDavid Majnemer2013-09-271-1/+1
| | | | | | | | | | | | The intent of getTypeOperand() was to yield an unqualified type. However QualType::getUnqualifiedType() does not strip away qualifiers on arrays. N.B. This worked fine when typeid() was applied to an expression because we would inject as implicit cast to the unqualified array type in the AST. llvm-svn: 191487
* Make IgnoreParens() look through ChooseExprs.Eli Friedman2013-07-201-1/+1
| | | | | | | | | | | | | This is the same way GenericSelectionExpr works, and it's generally a more consistent approach. A large part of this patch is devoted to caching the value of the condition of a ChooseExpr; it's needed to avoid threading an ASTContext into IgnoreParens(). Fixes <rdar://problem/14438917>. llvm-svn: 186738
* Make Expr::isConstantInitializer match IRGen.Eli Friedman2013-07-161-1/+5
| | | | | | | | | | Sema needs to be able to accurately determine what will be emitted as a constant initializer and what will not, so we get accurate errors in C and accurate -Wglobal-constructors warnings in C++. This makes Expr::isConstantInitializer match CGExprConstant as closely as possible. llvm-svn: 186464
* Rewrite record layout for ms_struct structs.Eli Friedman2013-06-261-30/+2
| | | | | | | | | | | | | | The old implementation of ms_struct in RecordLayoutBuilder was a complete mess: it depended on complicated conditionals which didn't really reflect the underlying logic, and placed a burden on users of the resulting RecordLayout. This commit rips out almost all of the old code, and replaces it with simple checks in RecordLayoutBuilder::LayoutBitField. This commit also fixes <rdar://problem/14252115>, a bug where class inheritance would cause us to lay out bitfields incorrectly. llvm-svn: 185018
OpenPOWER on IntegriCloud