summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGen/init.c
Commit message (Collapse)AuthorAgeFilesLines
* CodeGen: use non-zero memset when possible for automatic variablesJF Bastien2018-07-251-0/+66
| | | | | | | | | | | | | | | | | Summary: Right now automatic variables are either initialized with bzero followed by a few stores, or memcpy'd from a synthesized global. We end up encountering a fair amount of code where memcpy of non-zero byte patterns would be better than memcpy from a global because it touches less memory and generates a smaller binary. The optimizer could reason about this, but it's not really worth it when clang already knows. This code could definitely be more clever but I'm not sure it's worth it. In particular we could track a histogram of bytes seen and figure out (as we do with bzero) if a memset could be followed by a handful of stores. Similarly, we could tune the heuristics for GlobalSize, but using the same as for bzero seems conservatively OK for now. <rdar://problem/42563091> Reviewers: dexonsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D49771 llvm-svn: 337887
* Fix typo causing assert in self-host.Richard Smith2018-07-191-0/+11
| | | | llvm-svn: 337508
* When we choose to use zeroinitializer for a trailing portion of an arrayRichard Smith2018-07-191-0/+4
| | | | | | | | | | | 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
* CodeGen: specify alignment + inbounds for automatic variable initializationJF Bastien2018-07-131-25/+25
| | | | | | | | | | Summary: Automatic variable initialization was generating default-aligned stores (which are deprecated) instead of using the known alignment from the alloca. Further, they didn't specify inbounds. Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D49209 llvm-svn: 337041
* Use zeroinitializer for (trailing zero portion of) large array initializersRichard Smith2018-05-231-0/+10
| | | | | | | | 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-10/+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/+10
| | | | | | | | | | | | | | | | | | | | | | | 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
* [CodeGen] Initialize large arrays by copying from a globalIvan A. Kosarev2018-02-191-5/+18
| | | | | | | | | | | | | | Currently, clang compiles explicit initializers for array elements into series of store instructions. For large arrays of built-in types this results in bloated output code and significant amount of time spent on the instruction selection phase. This patch fixes the issue by initializing such arrays with global constants that store the binary image of the initializer. Differential Revision: https://reviews.llvm.org/D43181 llvm-svn: 325478
* Fixed processing of GNU extensions to C99 designated initializersAlexey Bataev2016-01-251-0/+11
| | | | | | Clang did not handles correctly inner parts of arrays/structures initializers in GNU extensions to C99 designated initializers. llvm-svn: 258668
* Test case updates for explicit type parameter to the gep operatorDavid Blaikie2015-03-131-2/+2
| | | | llvm-svn: 232187
* Update test case to make it easier to automatically port to typeless pointer ↵David Blaikie2015-03-131-2/+2
| | | | | | gep operator changes coming soon llvm-svn: 232185
* PR20473: Don't "deduplicate" string literals with the same value but differentRichard Smith2014-07-291-0/+8
| | | | | | | lengths! In passing, simplify string literal deduplication by relying on LLVM to deduplicate the underlying constant values. llvm-svn: 214222
* Rework the bitfield access IR generation to address PR13619 andChandler Carruth2012-12-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | generally support the C++11 memory model requirements for bitfield accesses by relying more heavily on LLVM's memory model. The primary change this introduces is to move from a manually aligned and strided access pattern across the bits of the bitfield to a much simpler lump access of all bits in the bitfield followed by math to extract the bits relevant for the particular field. This simplifies the code significantly, but relies on LLVM to intelligently lowering these integers. I have tested LLVM's lowering both synthetically and in benchmarks. The lowering appears to be functional, and there are no really significant performance regressions. Different code patterns accessing bitfields will vary in how this impacts them. The only real regressions I'm seeing are a few patterns where the LLVM code generation for loads that feed directly into a mask operation don't take advantage of the x86 ability to do a smaller load and a cheap zero-extension. This doesn't regress any benchmark in the nightly test suite on my box past the noise threshold, but my box is quite noisy. I'll be watching the LNT numbers, and will look into further improvements to the LLVM lowering as needed. llvm-svn: 169489
* CodeGen: When emitting stores for an initializer, only emit a GEP if we ↵Benjamin Kramer2012-08-271-0/+2
| | | | | | | | really need the store. This avoids emitting many dead GEPs for large zero-initialized arrays. llvm-svn: 162701
* Fix a stupid mistake in r151133. Reported to me by Joerg Sonnenberger.Eli Friedman2012-02-241-0/+7
| | | | llvm-svn: 151407
* Rename CGT::VerifyFuncTypeComplete to isFuncTypeConvertible sinceChris Lattner2011-07-101-0/+8
| | | | | | | | | | | | | | | | | | it is a predicate, not an action. Change the return type to be a bool, not the incomplete member. Enhace it to detect the recursive compilation case, allowing us to compile Eli's testcase on llvmdev: struct T { struct T (*p)(void); } t; into: %struct.T = type { {}* } @t = common global %struct.T zeroinitializer, align 8 llvm-svn: 134853
* implement a tiny amount of codegen support for gnu array range Chris Lattner2011-02-191-0/+15
| | | | | | | | designators: allowing codegen when the element initializer is a constant or something else without a side effect. This unblocks enough to let process.c in the linux kernel build, PR9257. llvm-svn: 126056
* Improve codegen for initializer lists to use memset more aggressivelyChris Lattner2010-12-021-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | when an initializer is variable (I handled the constant case in a previous patch). This has three pieces: 1. Enhance AggValueSlot to have a 'isZeroed' bit to tell CGExprAgg that the memory being stored into has previously been memset to zero. 2. Teach CGExprAgg to not emit stores of zero to isZeroed memory. 3. Teach CodeGenFunction::EmitAggExpr to scan initializers to determine whether they are profitable to emit a memset + inividual stores vs stores for everything. The heuristic used is that a global has to be more than 16 bytes and has to be 3/4 zero to be candidate for this xform. The two testcases are illustrative of the scenarios this catches. We now codegen test9 into: call void @llvm.memset.p0i8.i64(i8* %0, i8 0, i64 400, i32 4, i1 false) %.array = getelementptr inbounds [100 x i32]* %Arr, i32 0, i32 0 %tmp = load i32* %X.addr, align 4 store i32 %tmp, i32* %.array and test10 into: call void @llvm.memset.p0i8.i64(i8* %0, i8 0, i64 392, i32 8, i1 false) %tmp = getelementptr inbounds %struct.b* %S, i32 0, i32 0 %tmp1 = getelementptr inbounds %struct.a* %tmp, i32 0, i32 0 %tmp2 = load i32* %X.addr, align 4 store i32 %tmp2, i32* %tmp1, align 4 %tmp5 = getelementptr inbounds %struct.b* %S, i32 0, i32 3 %tmp10 = getelementptr inbounds %struct.a* %tmp5, i32 0, i32 4 %tmp11 = load i32* %X.addr, align 4 store i32 %tmp11, i32* %tmp10, align 4 Previously we produced 99 stores of zero for test9 and also tons for test10. This xforms should substantially speed up -O0 builds when it kicks in as well as reducing code size and optimizer heartburn on insane cases. This resolves PR279. llvm-svn: 120692
* Enhance the init generation logic to emit a memset followed by a few stores whenChris Lattner2010-12-021-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | a global is larger than 32 bytes and has fewer than 6 non-zero values in the initializer. Previously we'd turn something like this: char test8(int X) { char str[10000] = "abc"; into a 10K global variable which we then memcpy'd from. Now we generate: %str = alloca [10000 x i8], align 16 %tmp = getelementptr inbounds [10000 x i8]* %str, i64 0, i64 0 call void @llvm.memset.p0i8.i64(i8* %tmp, i8 0, i64 10000, i32 16, i1 false) store i8 97, i8* %tmp, align 16 %0 = getelementptr [10000 x i8]* %str, i64 0, i64 1 store i8 98, i8* %0, align 1 %1 = getelementptr [10000 x i8]* %str, i64 0, i64 2 store i8 99, i8* %1, align 2 Which is much smaller in space and also likely faster. This is part of PR279 llvm-svn: 120645
* Allow a string literal to initialize a tail array (PR8217), patch Chris Lattner2010-10-101-0/+12
| | | | | | by Pierre Habouzit! llvm-svn: 116165
* Don't consider casted non-global pointers to be evaluatable.John McCall2010-07-071-0/+6
| | | | | | Fixes rdar://problem/8154689 llvm-svn: 107755
* recommit r101568 to fix PR6766Nuno Lopes2010-04-181-3/+3
| | | | | | as a side-effect, remove two FIXMEs now fixed llvm-svn: 101726
* revert r101568, which miscompiles this testcase, distilled from ldecod:Chris Lattner2010-04-171-3/+3
| | | | | | | | | | void exit_picture() { char yuv_types[4][6]= {"4:0:0","4:2:0","4:2:2","4:4:4"}; foo(yuv_types); } llvm-svn: 101623
* fix PR6766: codegen of var initialized with wide charNuno Lopes2010-04-161-3/+3
| | | | llvm-svn: 101568
* add a codegen hack to work around an AST bug, allowing us to compile theChris Lattner2010-03-081-0/+11
| | | | | | code in PR6537. This should be reverted when the ast bug is fixed. llvm-svn: 97981
* Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.Daniel Dunbar2009-12-151-1/+1
| | | | | | | | | - This is designed to make it obvious that %clang_cc1 is a "test variable" which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it can be useful to redefine what gets run as 'clang -cc1' (for example, to set a default target). llvm-svn: 91446
* Eliminate &&s in tests.Daniel Dunbar2009-11-081-2/+2
| | | | | | - 'for i in $(find . -type f); do sed -e 's#\(RUN:.*[^ ]\) *&& *$#\1#g' $i | FileUpdate $i; done', for the curious. llvm-svn: 86430
* Rename clang to clang-cc.Daniel Dunbar2009-03-241-1/+1
| | | | | | Tests and drivers updated, still need to shuffle dirs. llvm-svn: 67602
* Set constant bit on static block vars as well. Patch by Anders Johnson!qDaniel Dunbar2009-02-131-1/+10
| | | | llvm-svn: 64502
* Upgrade the "excess elements in array initializer" warning to anDouglas Gregor2009-01-301-1/+0
| | | | | | | error, since both C99 and C++ consider it an error. For reference, GCC makes this a warning while G++ makes it an error. llvm-svn: 63435
* add a testcaseChris Lattner2008-05-041-1/+9
| | | | llvm-svn: 50608
* Simplify aggregate initilizer implementation. Use the ↵Lauro Ramos Venancio2008-02-191-0/+1
| | | | | | | | | CodeGenModule::EmitConstantExpr method when possible. Fix mediabench/mpeg2/mpeg2dec test. llvm-svn: 47336
* Implement multi-dimension array initalizer.Lauro Ramos Venancio2008-02-181-5/+12
| | | | | | Fix McCat/08-main test. llvm-svn: 47286
* Correctly handle constants that refer to enums.Anders Carlsson2008-01-291-2/+2
| | | | llvm-svn: 46481
* Correctly handle scalars in braces.Anders Carlsson2008-01-291-0/+7
llvm-svn: 46480
OpenPOWER on IntegriCloud