[PATCH] D46241: [CodeGen] Recognize more cases of zero initialization

[Serge Pavlov via Phabricator via cfe-commits]

sepavloff added a comment.

> Hmm. In C++, a static object which isn't constant-initialized is zero-initialized, which is required to set any padding bits to zero (N4640 [dcl.init]p6) in both structs and unions. In C, a static object which doesn't have an initializer also has all any padding bits set to zero (N1548 6.7.9p10). Now, this object has an initializer (that acts as a constant-initializer in C++), so those rules don't directly apply; but I would argue that the intent of the standards is not that padding bits become undefined when you happen to have an initializer. So I actually think the zeroinitializer emission is more correct.

Using undefined values instead of zero initialization was implemented in https://reviews.llvm.org/rL101535. There is no much info about the reason of the implementation. Clang uses undefined values for padding bits, in particular in unions, when the first member is not widest. The code:

      union C1 {
  	  char sel;
  	  double dval;
  	};
  	union C1 val_1 = { 0 };

produces:

  @val_1 = dso_local global { i8, [7 x i8] } { i8 0, [7 x i8] undef }, align 8	

Another case is unnamed bit fields.

  	struct C2 {
  	  int : 4;
  	  int x;
  	};
  	struct C2 val_2 = { 0 };

produces:

  @val_2 = dso_local global { [4 x i8], i32 } { [4 x i8] undef, i32 0 }, align 4

Strictly speaking, this IR does not mean violation of the standard, but it can modify code generation in some cases. If we decided to use zeroinitializer in this case, we probably would need to revise using undefined values in initializers, otherwise similar declarations like:

  	union C1 val_1a = { 0 };
  	union C1 val_1b = { 1 };

would produce different IR representations, with and without undefined values.

The test `SemaCXX/large-array-init.cpp` is removed in this change. This test was added in https://reviews.llvm.org/rL325120 to solve https://bugs.llvm.org/show_bug.cgi?id=18978, which describes the same problem, as solved by this patch. This patch presents more efficient solution, with it the tests compiles 50 time faster. If r325120 does not solve additional problems, it can be reverted.


Repository:
  rC Clang

https://reviews.llvm.org/D46241