Currently, you’re allowed to form a constant of aggregate type using any number of other constants you like. This makes scanning the instructions of the IR needlessly complex when looking for references to constants.
There is no need to support this degree of complexity in the IR. We could require that for anything but ‘zeroinitializer’ you cannot write a constant of aggregate (structure or array) type. You have to build it using insertvalue.
Thoughts? This would simplify several things I’m working on currently, and it is a super easy auto-upgrade and verifier addition.
Well, just to add a grain of salt, doing this won’t actually simplify anything very much. The reality is that ConstantExpr’s are much harder to handle than FCA Constants. =/
So, maybe this would be a small step in that direction, but that’s about it.
How would that work for VTables and such, which are global constants?
I have no problems with aggregate constant initializers for global
variables. We can support the syntax without allowing them through the
verifier inside of function bodies.
My real problem lies with operands which are aggregate constant values.
As I said in my followup though, this problem is strictly smaller than the
constantexpr problem, and may not be worth addressing separately.
I don’t see this as a good direction. We still need the ability to initialize global variables of FCA type.
If you’re interested in simplifying this space, I think that this would be a much more fruitful direction:
Constant expressions that can trap don’t make sense, for example.
What effect does this have on the readability of the IR?
Asking to make sure the point is considered, not because I neccessarily oppose your suggested change. My main concern would have been for global variable initializers, but it sounds like you've revised your proposal to exclude those.