summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGenCXX/cxx11-initializer-aggregate.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Use zeroinitializer for (trailing zero portion of) large array initializersRichard Smith2018-05-231-0/+68
| | | | | | | | 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-39/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+39
| | | | | | | | | | | | | | | | | | | | | | | 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-27/+0
| | | | | | initialization. llvm-svn: 332886
* [CodeGen] Recognize more cases of zero initializationSerge Pavlov2018-05-211-0/+27
| | | | | | | | | | | | | | | | | | | | | 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
* PR32044: Fix some cases where we would confuse a transparent init-list ↵Richard Smith2017-02-231-3/+12
| | | | | | expression with an aggregate init. llvm-svn: 296033
* Update Clang tests to handle explicitly typed gep changes in LLVM.David Blaikie2015-02-271-3/+3
| | | | llvm-svn: 230783
* Mark C++ reference parameters as dereferenceableHal Finkel2014-07-181-1/+1
| | | | | | | | | | | | | | Because references must be initialized using some evaluated expression, they must point to something, and a callee can assume the reference parameter is dereferenceable. Taking advantage of a new attribute just added to LLVM, mark them as such. Because dereferenceability in addrspace(0) implies nonnull in the backend, we don't need both attributes. However, we need to know the size of the object to use the dereferenceable attribute, so for incomplete types we still emit only nonnull. llvm-svn: 213386
* A non-trivial array-fill expression isn't necessarily a CXXConstructExpr. ItRichard Smith2014-06-131-0/+19
| | | | | | | could be an InitListExpr that runs constructors in C++11 onwards. Fixes a recent regression (introduced in r210091). llvm-svn: 210954
* Add 'nonnull' parameter or return attribute when producing an llvm pointer ↵Nick Lewycky2014-05-281-1/+1
| | | | | | type in a function type where the C++ type is a reference. Update the tests. llvm-svn: 209723
* Slightly generalize FileCheck patterns to unbreak -Asserts builds.Richard Smith2012-05-141-1/+1
| | | | llvm-svn: 156783
* Implement IRGen for C++11's "T{1, 2, 3}", where T is an aggregate and theRichard Smith2012-05-141-0/+25
expression is treated as an lvalue. llvm-svn: 156781
OpenPOWER on IntegriCloud