Should arrays be promoted to globals for LLVM on par codegen?

[bcardosolopes]

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.

Originally posted by @gitoleg in #370 (comment)