[CIR][Lowering] Implement cir.llvmir.zeroinit operation

[sitio-couto]

Stack from ghstack (oldest at bottom):

• [CIR][Lowering] Deprecate attributes for LLVM zero-initialization #221
• [CIR][Lowering][NFC] Rename LowerAttrToLLVMIR to LowerToLLVMIR #220
• [CIR][Lowering] Lower #cir.zero nested in initializer attributes #219
• -> [CIR][Lowering] Implement cir.llvmir.zeroinit operation #218
• [CIR][CIRGen] Update C++ codegen to use #cir.zero on structs #217
• [CIR][CIRGen] Implicitly zero-initialize global arrays elements #216

Due to the lack of zeroinitializer support in LLVM, some cases are
tricky to lower #cir.zero. An example is when an array is only partially
initialize with #cir.zero attributes. Since we can't just zeroinitialize
the whole array, the current #cir.zero attribute amend does not suffice.
To simplify the lowering, this patch introduces a new operation that is
solely used to generate zeroinitialize LLVM IR constants.

[bcardosolopes]

Due to the lack of zeroinitializer support in LLVM, some cases are tricky to lower #cir.zero. An example is when an array is only partially initialize with #cir.zero attributes. Since we can't just zeroinitialize the whole array, the current #cir.zero attribute amend does not suffice.

It seems like you're talking about scenarios where clang currently does early optimize and break initialization down to multiple instructions, examples from UnimplementedFeature's:

  // Clang early optimizations or things defered to LLVM lowering.
  static bool shouldUseBZeroPlusStoresToInitialize() { return false; }
  static bool shouldUseMemSetToInitialize() { return false; }
  static bool shouldSplitConstantStore() { return false; }
  static bool shouldCreateMemCpyFromGlobal() { return false; }
...

To simplify the lowering, this patch introduces a new operation that is solely used to generate zeroinitialize LLVM IR constants.

Instead of the approach on this patch, we should implement the relevant unimplemented feature that you're hitting as part of this use case, and lowering to more simple CIR in said LoweringPreparePass (please sync with Hongtao for which one of you is going to add it). The resulting CIR should then map 1-1 to what we expect LLVM codegen to be.

[bcardosolopes]

From comment

[sitio-couto]

It seems like you're talking about scenarios where clang currently does early optimize and break initialization down to multiple instructions

@bcardosolopes I'm not sure I follow. This change is meant to facilitate lowering #cir.zero to LLVM's dialect in general. The description is only one example where this is used.

Instead of the approach on this patch, we should implement the relevant unimplemented feature that you're hitting as part of this use case, and lowering to more simple CIR

Are you saying that the use of #cir.zero is an early optimization in itself and we should expand it to a regular initialization? E.g. #cir.zero : !cir.array<2 x !s8i> to #const_array<{0 : !s8i, 0 : !s8i}> : !cir.array<2 x !s8i>.

[bcardosolopes]

@bcardosolopes I'm not sure I follow. This change is meant to facilitate lowering #cir.zero to LLVM's dialect in general. The description is only one example where this is used.

Sorry, I probably dump more content than necessary for the comment. What I mean is: why there isn't a prepare pass lowering #cir.zero to a combo of CIR ops that allows LLVM lowering to map 1-1 from CIR?

Are you saying that the use of #cir.zero is an early optimization in itself and we should expand it to a regular initialization? E.g. #cir.zero : !cir.array<2 x !s8i> to #const_array<{0 : !s8i, 0 : !s8i}> : !cir.array<2 x !s8i>.

No, #cir.zero here is mostly syntax sugar.

[sitio-couto]

What I mean is: why there isn't a prepare pass lowering #cir.zero to a combo of CIR ops that allows LLVM lowering to map 1-1 from CIR?

@bcardosolopes mostly for two reasons:

• (Possibly) Wasted work
  LLVM's dialect will likely have, at some point, a better way to use the zeroinitialize LLVM IR feature. In this case, #cir.zero would already have a 1:1 mapping with LLVM's zeroinitialize and the pass to expand #cir.zero would not be required.
• Unnecessary overhead
  We could indeed expand #cir.zero to a series of CIR Ops that would map 1:1 with LLVM's Dialect and its current features, however, this would add overhead when expanding #cir.zero and lowering CIR->LLVM Dialect -> LLVM IR, as there would be more operations to handle. I'm not sure how large zero-initialized arrays would scale in this scenario as well (e.g. int arr[10000];).

Do you see any other benefits in this #cir.zero expansion other than a 1:1 mapping with the current state of LLVM's dialect?

[bcardosolopes]

Gotcha! Thanks for the detailed explanation, I understand the problem better now.

Can you instead add zeroinitialize attribute to LLVM IR dialect directly in the llvm-project (and add both Tobias Gysi and Alex Zinenko as reviewers)? As consumers, we should help improve LLVM IR dialect too.

I'm fine with this workaround once you have a patch submitted to MLIR, so we can more concretely know this isn't becoming technical debt :)

[bcardosolopes]

Per offline discussion: this is going to be used in the meantime, while @sitio-couto works on a PR for introducing this attribute in the LLVM dialect