Changes in init.c

532dc62b - [OpaquePtrs][Clang] Add -no-opaque-pointers to tests (NFC)

Thu, 07 Apr 2022 10:03:55 +0000

[OpaquePtrs][Clang] Add -no-opaque-pointers to tests (NFC)This adds -no-opaque-pointers to clang tests whose output willchange when opaque pointers are enabled by default. This isintended to be part of the migration approach described inhttps://discourse.llvm.org/t/enabling-opaque-pointers-by-default/61322/9.The patch has been produced by replacing %clang_cc1 with%clang_cc1 -no-opaque-pointers for tests that fail with opaquepointers enabled. Worth noting that this doesn't cover all tests,there's a remaining ~40 tests not using %clang_cc1 that will needa followup change.Differential Revision: https://reviews.llvm.org/D123115 List of files: /llvm-project-15.0.7/clang/test/CodeGen/init.c

adc402bf - Use functions with prototypes when appropriate; NFC

Tue, 15 Feb 2022 21:06:01 +0000

Use functions with prototypes when appropriate; NFCA significant number of our tests in C accidentally use functionswithout prototypes. This patch converts the function signatures to havea prototype for the situations where the test is not specific to K&R Cdeclarations. e.g., void func();becomes void func(void);This is the eleventh batch of tests being updated (there are asignificant number of other tests left to be updated). List of files: /llvm-project-15.0.7/clang/test/CodeGen/init.c

fd739804 - [test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differences

Thu, 31 Dec 2020 08:27:11 +0000

[test] Add {{.*}} to make ELF tests immune to dso_local/dso_preemptable/(none) differencesFor a default visibility external linkage definition, dso_local is set for ELF-fno-pic/-fpie and COFF and Mach-O. Since default clang -cc1 for ELF is similarto -fpic ("PIC Level" is not set), this nuance causes unneeded binary format differences.To make emitted IR similar, ELF -cc1 -fpic will default to -fno-semantic-interposition,which sets dso_local for default visibility external linkage definitions.To make this flip smooth and enable future (dso_local as definition default),this patch replaces (function) `define ` with `define{{.*}} `,(variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} `. List of files: /llvm-project-15.0.7/clang/test/CodeGen/init.c

dbc96b51 - Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition"

Mon, 03 Feb 2020 18:09:39 +0000

Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition"This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e.Accidentally committed. List of files: /llvm-project-15.0.7/clang/test/CodeGen/init.c

789a46f2 - [CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition

Sun, 02 Feb 2020 20:23:47 +0000

[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interpositionSummary:Clang -fpic defaults to -fno-semantic-interposition (GCC -fpic defaultsto -fsemantic-interposition).Users need to specify -fsemantic-interposition to get semanticinterposition behavior.Semantic interposition is currently a best-effort feature. There maystill be some cases where it is not handled well.Reviewers: peter.smith, rnk, serge-sans-paille, sfertile, jfb, jdoerfertSubscribers: dschuff, jyknight, dylanmckay, nemanjai, jvesely, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, arphaman, PkmX, jocewei, jsji, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, cfe-commitsTags: #clangDifferential Revision: https://reviews.llvm.org/D73865 List of files: /llvm-project-15.0.7/clang/test/CodeGen/init.c

6508929d - CodeGen: use non-zero memset when possible for automatic variables

Wed, 25 Jul 2018 04:29:03 +0000

CodeGen: use non-zero memset when possible for automatic variablesSummary: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.Reviewers: dexonsmithSubscribers: cfe-commitsDifferential Revision: https://reviews.llvm.org/D49771llvm-svn: 337887 List of files: /llvm-project-15.0.7/clang/test/CodeGen/init.c

4c656886 - Fix typo causing assert in self-host.

Thu, 19 Jul 2018 23:24:41 +0000

Fix typo causing assert in self-host.llvm-svn: 337508 List of files: /llvm-project-15.0.7/clang/test/CodeGen/init.c

83497d9e - When we choose to use zeroinitializer for a trailing portion of an array

Thu, 19 Jul 2018 21:38:56 +0000

When we choose to use zeroinitializer for a trailing portion of an arrayconstant, don't convert the rest into a packed struct.If an array constant has a large non-zero portion and a large zeroportion, we want to emit the first part as an array and the rest as azeroinitializer if possible. This fixes a memory usage regression fromr333141 when compiling PHP.llvm-svn: 337498 List of files: /llvm-project-15.0.7/clang/test/CodeGen/init.c

9aab85a6 - CodeGen: specify alignment + inbounds for automatic variable initialization

Fri, 13 Jul 2018 20:33:23 +0000

CodeGen: specify alignment + inbounds for automatic variable initializationSummary: 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-commitsDifferential Revision: https://reviews.llvm.org/D49209llvm-svn: 337041 List of files: /llvm-project-15.0.7/clang/test/CodeGen/init.c

3e268632 - Use zeroinitializer for (trailing zero portion of) large array initializers

Wed, 23 May 2018 23:41:38 +0000

Use zeroinitializer for (trailing zero portion of) large array initializersmore reliably.This re-commits r333044 with a fix for PR37560.llvm-svn: 333141 List of files: /llvm-project-15.0.7/clang/test/CodeGen/init.c

156349fa - Revert r333044 "Use zeroinitializer for (trailing zero portion of) large array initializers"

Wed, 23 May 2018 08:24:01 +0000

Revert r333044 "Use zeroinitializer for (trailing zero portion of) large 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/D47166llvm-svn: 333067 List of files: /llvm-project-15.0.7/clang/test/CodeGen/init.c

9062bbf4 - Use zeroinitializer for (trailing zero portion of) large array initializers

Wed, 23 May 2018 00:09:29 +0000

Use zeroinitializer for (trailing zero portion of) large array initializersmore reliably.Clang has two different ways it emits array constants (from InitListExprs andfrom APValues), and both had some ability to emit zeroinitializer, but neitherwas able to catch all cases where we could use zeroinitializer reliably. Inparticular, emitting from an APValue would fail to notice if all the explicitarray elements happened to be zero. In addition, for large arrays where only aninitial portion has an explicit initializer, we would emit the completeinitializer (which could be huge) rather than emitting only the non-zeroportion. With this change, when the element would have a suffix of more than 8zero elements, we emit the array constant as a packed struct of its initialportion followed by a zeroinitializer constant for the trailing zero portion.In passing, I found a bug where SemaInit would sometimes walk the entire arraywhen checking an initializer that only covers the first few elements; that'sfixed here to unblock testing of the rest.Differential Revision: https://reviews.llvm.org/D47166llvm-svn: 333044 List of files: /llvm-project-15.0.7/clang/test/CodeGen/init.c

e0ef348c - [CodeGen] Initialize large arrays by copying from a global

Mon, 19 Feb 2018 09:49:11 +0000

[CodeGen] Initialize large arrays by copying from a globalCurrently, clang compiles explicit initializers for arrayelements into series of store instructions. For large arrays ofbuilt-in types this results in bloated output code andsignificant amount of time spent on the instruction selectionphase. This patch fixes the issue by initializing such arrayswith global constants that store the binary image of theinitializer.Differential Revision: https://reviews.llvm.org/D43181llvm-svn: 325478 List of files: /llvm-project-15.0.7/clang/test/CodeGen/init.c

86a489e4 - Fixed processing of GNU extensions to C99 designated initializers

Mon, 25 Jan 2016 05:14:03 +0000

Fixed processing of GNU extensions to C99 designated initializersClang did not handles correctly inner parts of arrays/structures initializers in GNU extensions to C99 designated initializers. llvm-svn: 258668 List of files: /llvm-project-15.0.7/clang/test/CodeGen/init.c

bdf40a62 - Test case updates for explicit type parameter to the gep operator

Fri, 13 Mar 2015 18:21:46 +0000

Test case updates for explicit type parameter to the gep operatorllvm-svn: 232187 List of files: /llvm-project-15.0.7/clang/test/CodeGen/init.c

81e96f81 - Update test case to make it easier to automatically port to typeless pointer gep operator changes coming soon

Fri, 13 Mar 2015 18:21:11 +0000

Update test case to make it easier to automatically port to typeless pointer gep operator changes coming soonllvm-svn: 232185 List of files: /llvm-project-15.0.7/clang/test/CodeGen/init.c

00db2f13 - PR20473: Don't "deduplicate" string literals with the same value but different

Tue, 29 Jul 2014 21:20:12 +0000

PR20473: Don't "deduplicate" string literals with the same value but differentlengths! In passing, simplify string literal deduplication by relying on LLVMto deduplicate the underlying constant values.llvm-svn: 214222 List of files: /llvm-project-15.0.7/clang/test/CodeGen/init.c

ff0e3a1e - Rework the bitfield access IR generation to address PR13619 and

Thu, 06 Dec 2012 11:14:44 +0000

Rework the bitfield access IR generation to address PR13619 andgenerally support the C++11 memory model requirements for bitfieldaccesses by relying more heavily on LLVM's memory model.The primary change this introduces is to move from a manually alignedand strided access pattern across the bits of the bitfield to a muchsimpler lump access of all bits in the bitfield followed by math toextract the bits relevant for the particular field.This simplifies the code significantly, but relies on LLVM tointelligently lowering these integers.I have tested LLVM's lowering both synthetically and in benchmarks. Thelowering appears to be functional, and there are no really significantperformance regressions. Different code patterns accessing bitfieldswill vary in how this impacts them. The only real regressions I'm seeingare a few patterns where the LLVM code generation for loads that feeddirectly into a mask operation don't take advantage of the x86 abilityto do a smaller load and a cheap zero-extension. This doesn't regressany benchmark in the nightly test suite on my box past the noisethreshold, 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 List of files: /llvm-project-15.0.7/clang/test/CodeGen/init.c

46cbe77b - CodeGen: When emitting stores for an initializer, only emit a GEP if we really need the store.

Mon, 27 Aug 2012 21:35:58 +0000

CodeGen: When emitting stores for an initializer, only emit a GEP if we really need the store.This avoids emitting many dead GEPs for large zero-initialized arrays.llvm-svn: 162701 List of files: /llvm-project-15.0.7/clang/test/CodeGen/init.c

cb3785e4 - Fix a stupid mistake in r151133. Reported to me by Joerg Sonnenberger.

Fri, 24 Feb 2012 23:53:49 +0000

Fix a stupid mistake in r151133. Reported to me by Joerg Sonnenberger.llvm-svn: 151407 List of files: /llvm-project-15.0.7/clang/test/CodeGen/init.c