[CIR][Lowering] supports lowering of const arrays of structs

[gitoleg]

This PR fixes CIR lowering for the next case.

void foo() {
    struct {
        int a;
        int b;
    } a[1] = {{0,1}}; 
}

Note, we don't create attribute here and lower such const arrays as values.

[bcardosolopes]

Note, we don't create attribute here and lower such const arrays as values.

Fair, I do wonder in the long run if, during LoweringPrepare, we want to promote array values as globals so we get closer to mirror traditional LLVM codegen output more closely, such LLVM output will likely be more willing to allow optimizations in the LLVM pipeline to later kick-in. Thoughts?

[bcardosolopes]

LGTM after fixing conflicts

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[gitoleg]

LGTM after fixing conflicts

@bcardosolopes done! refactored a bit

Fair, I do wonder in the long run if, during LoweringPrepare, we want to promote array values as globals so we get closer to mirror traditional LLVM codegen output more closely, such LLVM output will likely be more willing to allow optimizations in the LLVM pipeline to later kick-in. Thoughts?

Well, yes. I faced with the same issue in the #393 . And I'm sure we should not touch LoweringPrepare until we fix unimplemented features. Actually, I already tried for that PR - and it was terrible, so I discarded all the changes.

And the original codegen emit memcpy or memset approximately here. And it's important to notice, that it's done on the codegen stage. I.e. memcpy from a global var is also created there.
I add LLVM IR just for the reference (for the example from above):

@__const.foo.a = private unnamed_addr constant [1 x %struct.anon] [%struct.anon { i32 0, i32 1 }], align 4

; Function Attrs: noinline nounwind optnone uwtable
define dso_local void @foo() #0 {
entry:
  %a = alloca [1 x %struct.anon], align 4
  call void @llvm.memcpy.p0.p0.i64(ptr align 4 %a, ptr align 4 @__const.foo.a, i64 8, i1 false)
  ret void
}

So I would say - first we need to implement all this unimplemented features and take a look, what do we get. And only after do something in the lowering prepare.

[bcardosolopes]

So I would say - first we need to implement all this unimplemented features and take a look, what do we get. And only after do something in the lowering prepare.

Totally agree, tracking in #403

[bcardosolopes]

LGTM