aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/CodeGen/CGExprConstant.cpp
AgeCommit message (Collapse)AuthorFilesLines
2020-06-15Revert "Prevent IR-gen from emitting consteval declarations"Kirill Bobyrev1-18/+0
This reverts commit 3bab88b7baa20b276faaee0aa7ca87f636c91877. This patch causes test failures: http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/17260
2020-06-15Prevent IR-gen from emitting consteval declarationsTyker1-0/+18
Summary: with this patch instead of emitting calls to consteval function. the IR-gen will emit a store of the already computed result. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D76420
2020-04-15Rework how UuidAttr, CXXUuidofExpr, and GUID template arguments and ↵Richard Smith1-6/+3
constants are represented. Summary: Previously, we treated CXXUuidofExpr as quite a special case: it was the only kind of expression that could be a canonical template argument, it could be a constant lvalue base object, and so on. In addition, we represented the UUID value as a string, whose source form we did not preserve faithfully, and that we partially parsed in multiple different places. With this patch, we create an MSGuidDecl object to represent the implicit object of type 'struct _GUID' created by a UuidAttr. Each UuidAttr holds a pointer to its 'struct _GUID' and its original (as-written) UUID string. A non-value-dependent CXXUuidofExpr behaves like a DeclRefExpr denoting that MSGuidDecl object. We cache an APValue representation of the GUID on the MSGuidDecl and use it from constant evaluation where needed. This allows removing a lot of the special-case logic to handle these expressions. Unfortunately, many parts of Clang assume there are only a couple of interesting kinds of ValueDecl, so the total amount of special-case logic is not really reduced very much. This fixes a few bugs and issues: * PR38490: we now support reading from GUID objects returned from __uuidof during constant evaluation. * Our Itanium mangling for a non-instantiation-dependent template argument involving __uuidof no longer depends on which CXXUuidofExpr template argument we happened to see first. * We now predeclare ::_GUID, and permit use of __uuidof without any header inclusion, better matching MSVC's behavior. We do not predefine ::__s_GUID, though; that seems like a step too far. * Our IR representation for GUID constants now uses the correct IR type wherever possible. We will still fall back to using the {i32, i16, i16, [8 x i8]} layout if a definition of struct _GUID is not available. This is not ideal: in principle the two layouts could have different padding. Reviewers: rnk, jdoerfert Subscribers: arphaman, cfe-commits, aeubanks Tags: #clang Differential Revision: https://reviews.llvm.org/D78171
2020-04-06Remove SequentialType from the type heirarchy.Eli Friedman1-2/+11
Now that we have scalable vectors, there's a distinction that isn't getting captured in the original SequentialType: some vectors don't have a known element count, so counting the number of elements doesn't make sense. In some cases, there's a better way to express the commonality using other methods. If we're dealing with GEPs, there's GEP methods; if we're dealing with a ConstantDataSequential, we can query its element type directly. In the relatively few remaining cases, I just decided to write out the type checks. We're talking about relatively few places, and I think the abstraction doesn't really carry its weight. (See thread "[RFC] Refactor class hierarchy of VectorType in the IR" on llvmdev.) Differential Revision: https://reviews.llvm.org/D75661
2020-04-02[Clang][CodeGen] Fixing mismatch between memory layout and const expressions ↵Lucas Prates1-5/+7
for oversized bitfields Summary: The construction of constants for structs/unions was conflicting the expected memory layout for over-sized bit-fields. When building the necessary bits for those fields, clang was ignoring the size information computed for the struct/union memory layout and using the original data from the AST's FieldDecl information. This caused an issue in big-endian targets, where the field's contant was incorrectly misplaced due to endian calculations. This patch aims to separate the constant value from the necessary padding bits, using the proper size information for each one of them. With this, the layout of constants for over-sized bit-fields matches the ABI requirements. Reviewers: rsmith, eli.friedman, efriedma Reviewed By: efriedma Subscribers: efriedma, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77048
2020-03-20[CodeGen] Emit destructor calls to destruct non-trivial C struct objectsAkira Hatanaka1-3/+1
returned by function calls or loaded from volatile objects rdar://problem/51867864 Differential Revision: https://reviews.llvm.org/D66094
2020-02-06C++ DR2026: static storage duration variables are not zeroed beforeRichard Smith1-13/+1
constant initialization. Removing this zeroing regressed our code generation in a few cases, also fixed here. We now compute whether a variable has constant destruction even if it doesn't have a constant initializer, by trying to destroy a default-initialized value, and skip emitting a trivial default constructor for a variable even if it has non-trivial (but perhaps constant) destruction.
2019-12-18Use hasOffsetApplied to initialize member HasOffsetAppliedAkira Hatanaka1-1/+1
This is NFC since none of the constructor calls in trunk pass hasOffsetApplied=true.
2019-12-09Avoid Attr.h includes, CodeGen editionReid Kleckner1-2/+3
This saves around 20 includes of Attr.h. Not much.
2019-11-19[NFC] Refactor representation of materialized temporariesTyker1-3/+3
Summary: this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63640#inline-612718 Reviewers: rsmith, martong, shafik Reviewed By: rsmith Subscribers: thakis, sammccall, ilya-biryukov, rnkovacs, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69360
2019-11-17Revert "[NFC] Refactor representation of materialized temporaries"Nico Weber1-3/+3
This reverts commit 08ea1ee2db5f9d6460fef1d79d0d1d1a5eb78982. It broke ./ClangdTests/FindExplicitReferencesTest.All on the bots, see comments on https://reviews.llvm.org/D69360
2019-11-16[NFC] Refactor representation of materialized temporariesTyker1-3/+3
Summary: this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63640#inline-612718 Reviewers: rsmith, martong, shafik Reviewed By: rsmith Subscribers: rnkovacs, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69360
2019-10-16CGExprConstant - silence static analyzer getAs<> null dereference warning. NFCI.Simon Pilgrim1-2/+2
The static analyzer is warning about a potential null dereference, but in these cases we should be able to use castAs<> directly and if not assert will fire for us. llvm-svn: 374988
2019-10-03[Alignment][Clang][NFC] Add CharUnits::getAsAlignGuillaume Chatelet1-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
2019-10-03Silence static analyzer getAs<RecordType> null dereference warnings. NFCI.Simon Pilgrim1-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
2019-07-16Fix parameter name comments using clang-tidy. NFC.Rui Ueyama1-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
2019-07-03Change std::{lower,upper}_bound to llvm::{lower,upper}_bound or ↵Fangrui Song1-1/+1
llvm::partition_point. NFC llvm-svn: 365006
2019-07-02[C++2a] Add __builtin_bit_cast, used to implement std::bit_castErik Pilkington1-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
2019-06-22Remove reliance on toCharUnitsFromBits rounding down.Richard Smith1-1/+2
llvm-svn: 364139
2019-06-20P0840R2: support for [[no_unique_address]] attributeRichard Smith1-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
2019-06-18Fix compiler warning by removing unused variableMikael Holmen1-1/+1
llvm-svn: 363651
2019-06-17Rewrite ConstStructBuilder with a mechanism that can cope with splitting and ↵Richard Smith1-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
2019-05-22Modules: Code generation of enum constants for merged enum definitionsDavid Blaikie1-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
2019-05-21Refactor: split Uninitialized state on APValue into an "Absent" stateRichard Smith1-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
2019-05-17Refactor constant evaluation of typeid(T) to track a symbolic type_infoRichard Smith1-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
2019-05-17Revert Refactor constant evaluation of typeid(T) to track a symbolic ↵Chris Bieneman1-11/+0
type_info object rather than tracking the originating expression. This reverts r360974 (git commit 7ee4307bd4450022c3c8777f43a40cc4f0ccc009) llvm-svn: 360988
2019-05-17Refactor constant evaluation of typeid(T) to track a symbolic type_infoRichard Smith1-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
2019-05-16Implement __builtin_LINE() et. al. to support source location capture.Eric Fiselier1-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
2019-05-11ConstantLValueEmitter::tryEmitAbsolute - remove unused variable. NFCI.Simon Pilgrim1-3/+1
Duplicate getOffset() call. llvm-svn: 360515
2019-04-24Use llvm::stable_sortFangrui Song1-1/+1
llvm-svn: 359098
2019-03-19Refactor cast<>'s in if conditionals, which can only assert on failure.Don Hinton1-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
2019-03-08[ObjC] Emit a boxed expression as a compile-time constant if theAkira Hatanaka1-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
2019-03-06[Fixed Point Arithmetic] Fixed Point and Integer ConversionsLeonard Chan1-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
2019-02-08[CodeGen][NFC] Update comments in CGExprConstant.cpp.Eli Friedman1-5/+8
llvm-svn: 353571
2019-02-08[Sema] Make string literal init an rvalue.Eli Friedman1-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
2019-01-22[CodeGen] Always use string computed in Sema for PredefinedExprEli Friedman1-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
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-16[Fixed Point Arithmetic] Add APFixedPoint to APValueLeonard Chan1-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
2018-12-01Correct indentation.Bill Wendling1-1/+1
llvm-svn: 348071
2018-12-01Specify constant context in constant emitterBill Wendling1-1/+2
The constant emitter may need to evaluate the expression in a constant context. For exasmple, global initializer lists. llvm-svn: 348070
2018-11-30Revert r348029. I was git-ing and jumped the gun.Bill Wendling1-2/+1
llvm-svn: 348032
2018-11-30We're in a constant context in the ConstantEmitter.Bill Wendling1-1/+2
llvm-svn: 348029
2018-11-09Compound literals, enums, et al require const exprBill Wendling1-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
2018-11-02[CodeGen] Fix a crash when updating a designated initializerErik Pilkington1-8/+8
We need to handle the ConstantAggregateZero case here too. rdar://45691981 Differential revision: https://reviews.llvm.org/D54010 llvm-svn: 346004
2018-10-27[AST] Refactor PredefinedExprBruno Ricci1-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
2018-10-23[Fixed Point Arithmetic] Fixed Point to Boolean CastLeonard Chan1-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
2018-10-23[OpenCL][NFC] Unify ZeroToOCL* cast typesAndrew Savonichev1-2/+1
Reviewers: Anastasia, yaxunl Reviewed By: Anastasia Subscribers: asavonic, cfe-commits Differential Revision: https://reviews.llvm.org/D52654 llvm-svn: 345038
2018-10-15[Fixed Point Arithmetic] FixedPointCastLeonard Chan1-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
2018-08-08[CodeGen] IncompleteArray Support Balaji V. Iyer1-0/+10
Added code to support ArrayType that is not ConstantArray. https://reviews.llvm.org/D49952 rdar://42476155 llvm-svn: 339207
2018-07-30Remove trailing spaceFangrui Song1-17/+17
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
generated by cgit v1.1 at 2025-09-30 18:31:39 +0000