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. -Chandler -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140203/0cad91b4/attachment.html>
Bleh. 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. On Mon, Feb 3, 2014 at 1:24 AM, Chandler Carruth <chandlerc at google.com>wrote:> 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. > > -Chandler >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140203/f63e733f/attachment.html>
On 3 February 2014 09:24, Chandler Carruth <chandlerc at google.com> wrote:> 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.How would that work for VTables and such, which are global constants? Tim.
On Mon, Feb 3, 2014 at 3:44 AM, Tim Northover <t.p.northover at gmail.com>wrote:> On 3 February 2014 09:24, Chandler Carruth <chandlerc at google.com> wrote: > > 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. > > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140203/348957d4/attachment.html>
On Feb 3, 2014, at 2:07 AM, Chandler Carruth <chandlerc at google.com> wrote:> Bleh. > > 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.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: http://llvm.org/bugs/show_bug.cgi?id=10368 Constant expressions that can trap don’t make sense, for example. -Chris
On 2/3/14 1:24 AM, Chandler Carruth wrote:> 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. > > -ChandlerWhat 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. Philip