summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGExprConstant.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [Alignment][Clang][NFC] Add CharUnits::getAsAlignGuillaume Chatelet2019-10-031-1/+1
| | | | | | | | | | | | | | | | | | Summary: This is a prerequisite to removing `llvm::GlobalObject::setAlignment(unsigned)`. This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jholewinski, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68274 llvm-svn: 373592
* Silence static analyzer getAs<RecordType> null dereference warnings. NFCI.Simon Pilgrim2019-10-031-2/+2
| | | | | | The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<RecordType> directly and if not assert will fire for us. llvm-svn: 373584
* Fix parameter name comments using clang-tidy. NFC.Rui Ueyama2019-07-161-1/+1
| | | | | | | | | | | | | | | | | | | | | This patch applies clang-tidy's bugprone-argument-comment tool to LLVM, clang and lld source trees. Here is how I created this patch: $ git clone https://github.com/llvm/llvm-project.git $ cd llvm-project $ mkdir build $ cd build $ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \ -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \ -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm $ ninja $ parallel clang-tidy -checks='-*,bugprone-argument-comment' \ -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \ ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h} llvm-svn: 366177
* Change std::{lower,upper}_bound to llvm::{lower,upper}_bound or ↵Fangrui Song2019-07-031-1/+1
| | | | | | llvm::partition_point. NFC llvm-svn: 365006
* [C++2a] Add __builtin_bit_cast, used to implement std::bit_castErik Pilkington2019-07-021-0/+1
| | | | | | | | | | | | | | | | | | This commit adds a new builtin, __builtin_bit_cast(T, v), which performs a bit_cast from a value v to a type T. This expression can be evaluated at compile time under specific circumstances. The compile time evaluation currently doesn't support bit-fields, but I'm planning on fixing this in a follow up (some of the logic for figuring this out is in CodeGen). I'm also planning follow-ups for supporting some more esoteric types that the constexpr evaluator supports, as well as extending __builtin_memcpy constexpr evaluation to use the same infrastructure. rdar://44987528 Differential revision: https://reviews.llvm.org/D62825 llvm-svn: 364954
* Remove reliance on toCharUnitsFromBits rounding down.Richard Smith2019-06-221-1/+2
| | | | llvm-svn: 364139
* P0840R2: support for [[no_unique_address]] attributeRichard Smith2019-06-201-8/+18
| | | | | | | | | | | | | | | | | Summary: Add support for the C++2a [[no_unique_address]] attribute for targets using the Itanium C++ ABI. This depends on D63371. Reviewers: rjmccall, aaron.ballman Subscribers: dschuff, aheejin, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63451 llvm-svn: 363976
* Fix compiler warning by removing unused variableMikael Holmen2019-06-181-1/+1
| | | | llvm-svn: 363651
* Rewrite ConstStructBuilder with a mechanism that can cope with splitting and ↵Richard Smith2019-06-171-495/+636
| | | | | | | | | | | | | | | | | | | | | | | | updating constants. Summary: This adds a ConstantBuilder class that deals with incrementally building an aggregate constant, including support for overwriting previously-emitted parts of the aggregate with new values. This fixes a bunch of cases where we used to be unable to reduce a DesignatedInitUpdateExpr down to an IR constant, and also lays some groundwork for emission of class constants with [[no_unique_address]] members. Reviewers: rjmccall Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63371 llvm-svn: 363620
* Modules: Code generation of enum constants for merged enum definitionsDavid Blaikie2019-05-221-1/+1
| | | | | | | | | | | | | | | Found in a bootstrap of LLVM with implicit modules, resulting in a deadlock of some Orc unit tests with libstdc++ 8.1. An enum was used as part of the implementation of std::recursive_mutex and this bug resulted in the constant initialization of zero instead of the desired non-zero value. => Badness. Richard Smith tells me neither of these fields are necessarily canonical & so using declaresSamEntity is the right solution here (rather than changing both of these Fields to be canonical by construction/from their source) llvm-svn: 361428
* Refactor: split Uninitialized state on APValue into an "Absent" stateRichard Smith2019-05-211-2/+4
| | | | | | | representing no such object, and an "Indeterminate" state representing an uninitialized object. The latter is not yet used, but soon will be. llvm-svn: 361328
* Refactor constant evaluation of typeid(T) to track a symbolic type_infoRichard Smith2019-05-171-0/+11
| | | | | | | | | | | | | | object rather than tracking the originating expression. This is groundwork for supporting polymorphic typeid expressions. (Note that this somewhat regresses our support for DR1968, but it turns out that that never actually worked anyway, at least in non-trivial cases.) This reinstates r360974, reverted in r360988, with a fix for a static_assert failure on 32-bit builds: force Type base class to have 8-byte alignment like the rest of Clang's AST nodes. llvm-svn: 360995
* Revert Refactor constant evaluation of typeid(T) to track a symbolic ↵Chris Bieneman2019-05-171-11/+0
| | | | | | | | type_info object rather than tracking the originating expression. This reverts r360974 (git commit 7ee4307bd4450022c3c8777f43a40cc4f0ccc009) llvm-svn: 360988
* Refactor constant evaluation of typeid(T) to track a symbolic type_infoRichard Smith2019-05-171-0/+11
| | | | | | | | | | object rather than tracking the originating expression. This is groundwork for supporting polymorphic typeid expressions. (Note that this somewhat regresses our support for DR1968, but it turns out that that never actually worked anyway, at least in non-trivial cases.) llvm-svn: 360974
* Implement __builtin_LINE() et. al. to support source location capture.Eric Fiselier2019-05-161-4/+0
| | | | | | | | | | | | | | | | | Summary: This patch implements the source location builtins `__builtin_LINE(), `__builtin_FUNCTION()`, `__builtin_FILE()` and `__builtin_COLUMN()`. These builtins are needed to implement [`std::experimental::source_location`](https://rawgit.com/cplusplus/fundamentals-ts/v2/main.html#reflection.src_loc.creation). With the exception of `__builtin_COLUMN`, GCC also implements these builtins, and Clangs behavior is intended to match as closely as possible. Reviewers: rsmith, joerg, aaron.ballman, bogner, majnemer, shafik, martong Reviewed By: rsmith Subscribers: rnkovacs, loskutov, riccibruno, mgorny, kunitoki, alexr, majnemer, hfinkel, cfe-commits Differential Revision: https://reviews.llvm.org/D37035 llvm-svn: 360937
* ConstantLValueEmitter::tryEmitAbsolute - remove unused variable. NFCI.Simon Pilgrim2019-05-111-3/+1
| | | | | | Duplicate getOffset() call. llvm-svn: 360515
* Use llvm::stable_sortFangrui Song2019-04-241-1/+1
| | | | llvm-svn: 359098
* Refactor cast<>'s in if conditionals, which can only assert on failure.Don Hinton2019-03-191-25/+14
| | | | | | | | | | | | | | | | | Summary: This patch refactors several instances of cast<> used in if conditionals. Since cast<> asserts on failure, the else branch can never be taken. In some cases, the fix is to replace cast<> with dyn_cast<>. While others required the removal of the conditional and some minor refactoring. A discussion can be seen here: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190318/265044.html Differential Revision: https://reviews.llvm.org/D59529 llvm-svn: 356441
* [ObjC] Emit a boxed expression as a compile-time constant if theAkira Hatanaka2019-03-081-2/+17
| | | | | | | | | | | | | | | | | | expression inside the parentheses is a valid UTF-8 string literal. Previously clang emitted an expression like @("abc") as a message send to stringWithUTF8String. This commit makes clang emit the boxed expression as a compile-time constant instead. This commit also has the effect of silencing the nullable-to-nonnull conversion warning clang started emitting after r317727, which originally motivated this commit (see https://oleb.net/2018/@keypath). rdar://problem/42684601 Differential Revision: https://reviews.llvm.org/D58729 llvm-svn: 355662
* [Fixed Point Arithmetic] Fixed Point and Integer ConversionsLeonard Chan2019-03-061-0/+2
| | | | | | | | | This patch includes the necessary code for converting between a fixed point type and integer. This also includes constant expression evaluation for conversions with these types. Differential Revision: https://reviews.llvm.org/D56900 llvm-svn: 355462
* [CodeGen][NFC] Update comments in CGExprConstant.cpp.Eli Friedman2019-02-081-5/+8
| | | | llvm-svn: 353571
* [Sema] Make string literal init an rvalue.Eli Friedman2019-02-081-10/+0
| | | | | | | | | | | | | | | | | | | | | | | This allows substantially simplifying the expression evaluation code, because we don't have to special-case lvalues which are actually string literal initialization. This currently throws away an optimization where we would avoid creating an array APValue for string literal initialization. If we really want to optimize this case, we should fix APValue so it can store simple arrays more efficiently, like llvm::ConstantDataArray. This shouldn't affect the memory usage for other string literals. (Not sure if this is a blocker; I don't think string literal init is common enough for this to be a serious issue, but I could be wrong.) The change to test/CodeGenObjC/encode-test.m is a weird side-effect of these changes: we currently don't constant-evaluate arrays in C, so the strlen call shouldn't be folded, but lvalue string init managed to get around that check. I this this is fine. Fixes https://bugs.llvm.org/show_bug.cgi?id=40430 . llvm-svn: 353569
* [CodeGen] Always use string computed in Sema for PredefinedExprEli Friedman2019-01-221-11/+1
| | | | | | | | | | | | | | | | | | | | | | | | We can't use any other string, anyway, because its type wouldn't match the type of the PredefinedExpr. With this change, we don't compute a "nice" name for the __func__ global when it's used in the initializer for a constant. This doesn't seem like a great loss, and I'm not sure how to fix it without either storing more information in the AST, or somehow threading through the information from ExprConstant.cpp. This could break some situations involving BlockDecl; currently, CodeGenFunction::EmitPredefinedLValue has some logic to intentionally emit a string different from what Sema computed. This code skips that logic... but that logic can't work correctly in general anyway. (For example, sizeof(__func__) returns the wrong result.) Hopefully this doesn't affect practical code. Fixes https://bugs.llvm.org/show_bug.cgi?id=40313 . Differential Revision: https://reviews.llvm.org/D56821 llvm-svn: 351766
* 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
* [Fixed Point Arithmetic] Add APFixedPoint to APValueLeonard Chan2019-01-161-0/+3
| | | | | | | | This adds APFixedPoint to the union of values that can be represented with an APValue. Differential Revision: https://reviews.llvm.org/D56746 llvm-svn: 351368
* Correct indentation.Bill Wendling2018-12-011-1/+1
| | | | llvm-svn: 348071
* Specify constant context in constant emitterBill Wendling2018-12-011-1/+2
| | | | | | | The constant emitter may need to evaluate the expression in a constant context. For exasmple, global initializer lists. llvm-svn: 348070
* Revert r348029. I was git-ing and jumped the gun.Bill Wendling2018-11-301-2/+1
| | | | llvm-svn: 348032
* We're in a constant context in the ConstantEmitter.Bill Wendling2018-11-301-1/+2
| | | | llvm-svn: 348029
* Compound literals, enums, et al require const exprBill Wendling2018-11-091-0/+10
| | | | | | | | | | | | | | | | | | Summary: Compound literals, enums, file-scoped arrays, etc. require their initializers and size specifiers to be constant. Wrap the initializer expressions in a ConstantExpr so that we can easily check for this later on. Reviewers: rsmith, shafik Reviewed By: rsmith Subscribers: cfe-commits, jyknight, nickdesaulniers Differential Revision: https://reviews.llvm.org/D53921 llvm-svn: 346455
* [CodeGen] Fix a crash when updating a designated initializerErik Pilkington2018-11-021-8/+8
| | | | | | | | | | We need to handle the ConstantAggregateZero case here too. rdar://45691981 Differential revision: https://reviews.llvm.org/D54010 llvm-svn: 346004
* [AST] Refactor PredefinedExprBruno Ricci2018-10-271-1/+1
| | | | | | | | | | | | | | | | | | Make the following changes to PredefinedExpr: 1. Move PredefinedExpr below StringLiteral so that it can use its definition. 2. Rename IdentType to IdentKind to be more in line with clang's conventions, and propagate the change to its users. 3. Move the location and the IdentKind into the newly available space of the bit-fields of Stmt. 4. Only store the function name when needed. When parsing all of Boost, of the 1357 PredefinedExpr 919 have no function name. Differential Revision: https://reviews.llvm.org/D53605 Reviewed By: rjmccall llvm-svn: 345460
* [Fixed Point Arithmetic] Fixed Point to Boolean CastLeonard Chan2018-10-231-0/+1
| | | | | | | | | | This patch is a part of https://reviews.llvm.org/D48456 in an attempt to split the casting logic up into smaller patches. This contains the code for casting from fixed point types to boolean types. Differential Revision: https://reviews.llvm.org/D53308 llvm-svn: 345063
* [OpenCL][NFC] Unify ZeroToOCL* cast typesAndrew Savonichev2018-10-231-2/+1
| | | | | | | | | | | | Reviewers: Anastasia, yaxunl Reviewed By: Anastasia Subscribers: asavonic, cfe-commits Differential Revision: https://reviews.llvm.org/D52654 llvm-svn: 345038
* [Fixed Point Arithmetic] FixedPointCastLeonard Chan2018-10-151-0/+1
| | | | | | | | | | | | | This patch is a part of https://reviews.llvm.org/D48456 in an attempt to split them up. This contains the code for casting between fixed point types and other fixed point types. The method for converting between fixed point types is based off the convert() method in APFixedPoint. Differential Revision: https://reviews.llvm.org/D50616 llvm-svn: 344530
* [CodeGen] IncompleteArray Support Balaji V. Iyer2018-08-081-0/+10
| | | | | | | | | Added code to support ArrayType that is not ConstantArray. https://reviews.llvm.org/D49952 rdar://42476155 llvm-svn: 339207
* Remove trailing spaceFangrui Song2018-07-301-17/+17
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* [AST] Add a convenient getter from QualType to RecordDeclGeorge Karpenkov2018-07-281-2/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D49951 llvm-svn: 338187
* Fix typo causing assert in self-host.Richard Smith2018-07-191-1/+1
| | | | llvm-svn: 337508
* When we choose to use zeroinitializer for a trailing portion of an arrayRichard Smith2018-07-191-1/+13
| | | | | | | | | | | constant, don't convert the rest into a packed struct. If an array constant has a large non-zero portion and a large zero portion, we want to emit the first part as an array and the rest as a zeroinitializer if possible. This fixes a memory usage regression from r333141 when compiling PHP. llvm-svn: 337498
* Use zeroinitializer for (trailing zero portion of) large array initializersRichard Smith2018-05-231-79/+91
| | | | | | | | more reliably. This re-commits r333044 with a fix for PR37560. llvm-svn: 333141
* Revert r333044 "Use zeroinitializer for (trailing zero portion of) large ↵Hans Wennborg2018-05-231-78/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | array initializers" It caused asserts, see PR37560. > Use zeroinitializer for (trailing zero portion of) large array initializers > more reliably. > > Clang has two different ways it emits array constants (from InitListExprs and > from APValues), and both had some ability to emit zeroinitializer, but neither > was able to catch all cases where we could use zeroinitializer reliably. In > particular, emitting from an APValue would fail to notice if all the explicit > array elements happened to be zero. In addition, for large arrays where only an > initial portion has an explicit initializer, we would emit the complete > initializer (which could be huge) rather than emitting only the non-zero > portion. With this change, when the element would have a suffix of more than 8 > zero elements, we emit the array constant as a packed struct of its initial > portion followed by a zeroinitializer constant for the trailing zero portion. > > In passing, I found a bug where SemaInit would sometimes walk the entire array > when checking an initializer that only covers the first few elements; that's > fixed here to unblock testing of the rest. > > Differential Revision: https://reviews.llvm.org/D47166 llvm-svn: 333067
* Use zeroinitializer for (trailing zero portion of) large array initializersRichard Smith2018-05-231-71/+78
| | | | | | | | | | | | | | | | | | | | | | | more reliably. Clang has two different ways it emits array constants (from InitListExprs and from APValues), and both had some ability to emit zeroinitializer, but neither was able to catch all cases where we could use zeroinitializer reliably. In particular, emitting from an APValue would fail to notice if all the explicit array elements happened to be zero. In addition, for large arrays where only an initial portion has an explicit initializer, we would emit the complete initializer (which could be huge) rather than emitting only the non-zero portion. With this change, when the element would have a suffix of more than 8 zero elements, we emit the array constant as a packed struct of its initial portion followed by a zeroinitializer constant for the trailing zero portion. In passing, I found a bug where SemaInit would sometimes walk the entire array when checking an initializer that only covers the first few elements; that's fixed here to unblock testing of the rest. Differential Revision: https://reviews.llvm.org/D47166 llvm-svn: 333044
* Revert r332847; it caused us to miscompile certain forms of reference ↵Richard Smith2018-05-211-30/+10
| | | | | | initialization. llvm-svn: 332886
* [CodeGen] Recognize more cases of zero initializationSerge Pavlov2018-05-211-10/+30
| | | | | | | | | | | | | | | | | | | | | If a variable has an initializer, codegen tries to build its value. If the variable is large in size, building its value requires substantial resources. It causes strange behavior from user viewpoint: compilation of huge zero initialized arrays like: char data_1[2147483648u] = { 0 }; consumes enormous amount of time and memory. With this change codegen tries to determine if variable initializer is equivalent to zero initializer. In this case variable value is not constructed. This change fixes PR18978. Differential Revision: https://reviews.llvm.org/D46241 llvm-svn: 332847
* [CodeGen] Use the zero initializer instead of storing an all zero ↵Matt Davis2018-02-091-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | representation. Summary: This change avoids the overhead of storing, and later crawling, an initializer list of all zeros for arrays. When LLVM visits this (llvm/IR/Constants.cpp) ConstantArray::getImpl() it will scan the list looking for an array of all zero. We can avoid the store, and short-cut the scan, by detecting all zeros when clang builds-up the initialization representation. This was brought to my attention when investigating PR36030 Reviewers: majnemer, rjmccall Reviewed By: rjmccall Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D42549 llvm-svn: 324776
* [CodeGen][X86] Fix handling of __fp16 vectors.Akira Hatanaka2017-12-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit fixes a bug in IRGen where it generates completely broken code for __fp16 vectors on X86. For example when the following code is compiled: half4 hv0, hv1, hv2; // these are vectors of __fp16. void foo221() { hv0 = hv1 + hv2; } clang generates the following IR, in which two i16 vectors are added: @hv1 = common global <4 x i16> zeroinitializer, align 8 @hv2 = common global <4 x i16> zeroinitializer, align 8 @hv0 = common global <4 x i16> zeroinitializer, align 8 define void @foo221() { %0 = load <4 x i16>, <4 x i16>* @hv1, align 8 %1 = load <4 x i16>, <4 x i16>* @hv2, align 8 %add = add <4 x i16> %0, %1 store <4 x i16> %add, <4 x i16>* @hv0, align 8 ret void } To fix the bug, this commit uses the code committed in r314056, which modified clang to promote and truncate __fp16 vectors to and from float vectors in the AST. It also fixes another IRGen bug where a short value is assigned to an __fp16 variable without any integer-to-floating-point conversion, as shown in the following example: __fp16 a; short b; void foo1() { a = b; } @b = common global i16 0, align 2 @a = common global i16 0, align 2 define void @foo1() #0 { %0 = load i16, i16* @b, align 2 store i16 %0, i16* @a, align 2 ret void } rdar://problem/20625184 Differential Revision: https://reviews.llvm.org/D40112 llvm-svn: 320215
* Convert clang::LangAS to a strongly typed enumAlexander Richardson2017-10-151-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Convert clang::LangAS to a strongly typed enum Currently both clang AST address spaces and target specific address spaces are represented as unsigned which can lead to subtle errors if the wrong type is passed. It is especially confusing in the CodeGen files as it is not possible to see what kind of address space should be passed to a function without looking at the implementation. I originally made this change for our LLVM fork for the CHERI architecture where we make extensive use of address spaces to differentiate between capabilities and pointers. When merging the upstream changes I usually run into some test failures or runtime crashes because the wrong kind of address space is passed to a function. By converting the LangAS enum to a C++11 we can catch these errors at compile time. Additionally, it is now obvious from the function signature which kind of address space it expects. I found the following errors while writing this patch: - ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address space to TargetInfo::getPointer{Width,Align}() - TypePrinter::printAttributedAfter() prints the numeric value of the clang AST address space instead of the target address space. However, this code is not used so I kept the current behaviour - initializeForBlockHeader() in CGBlocks.cpp was passing LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}() - CodeGenFunction::EmitBlockLiteral() was passing a AST address space to TargetInfo::getPointerWidth() - CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space to Qualifiers::addAddressSpace() - CGOpenMPRuntimeNVPTX::getParameterAddress() was using llvm::Type::getPointerTo() with a AST address space - clang_getAddressSpace() returns either a LangAS or a target address space. As this is exposed to C I have kept the current behaviour and added a comment stating that it is probably not correct. Other than this the patch should not cause any functional changes. Reviewers: yaxunl, pcc, bader Reviewed By: yaxunl, bader Subscribers: jlebar, jholewinski, nhaehnle, Anastasia, cfe-commits Differential Revision: https://reviews.llvm.org/D38816 llvm-svn: 315871
* Further refactoring of the constant emitter. NFC.John McCall2017-08-171-166/+288
| | | | llvm-svn: 311065
* Extract IRGen's constant-emitter into its own helper class and clean upJohn McCall2017-08-151-248/+585
| | | | | | | | | | | | the interface. The ultimate goal here is to make it easier to do some more interesting things in constant emission, like emit constant initializers that have ignorable side-effects, or doing the majority of an initialization in-place and then patching up the last few things with calls. But for now this is mostly just a refactoring. llvm-svn: 310964
OpenPOWER on IntegriCloud