On Feb 27, 2011, at 9:48 AM, Rafael Ávila de Espíndola wrote:>> Comments welcome! > > Having fewer types makes the job of the passes easier. Right now we > maintain a small number of types as we go, which is expensive. In the > proposed change, would it still be legal to write a type merging pass? > For example, lets say we have > > %Foo = type { i32 } > %Bar = type { i32 } > @a = unnamed_addr constant %Foo { i32 42 } > @a = unnamed_addr constant %Bar { i32 42 } > > The typemerge pass could turn this into > > @a = unnamed_addr constant {i32} { i32 42 } > @b = unnamed_addr constant {i32} { i32 42 } > > And constmerge will then merge them as it does today.I don't see this as requiring a type merging pass. A better way to handle this (IMO) would be to generalize constant merging to handle bit identities, which would allow it to merge things like: @a = unnamed constant i32 0 @b = unnamed constant float 0.0 This can be done today, and then the type system change won't affect constant merging.> Another comment is that getting anonymous types would still be a bit > expensive. Can we get away with just Named types (including Unnamed) and > trusting typemerge to do its job?Getting an anonymous type should be the same cost as getting a struct type today: just look it up in a (redesigned) uniquing table. However, as I just mentioned to Jan, it might be better to just drop the concept of anonymous types entirely. This would simplify the model and is even closer to what we have today. -Chris
> I don't see this as requiring a type merging pass. A better way to > handle this (IMO) would be to generalize constant merging to handle > bit identities, which would allow it to merge things like: > > @a = unnamed constant i32 0 @b = unnamed constant float 0.0 > > This can be done today, and then the type system change won't affect > constant merging.It is true that it is better to have passes know that different types can have the same bits, but a type merging pass would still be useful for the passes that have not been updated or just for reducing the size of a bitcode file. The main question is if such a pass would be legal, or if we would guarantee that Foo and Bar in the above examples would remain as two different types.> > -ChrisThanks, Rafael
On Feb 27, 2011, at 12:50 PM, Rafael Ávila de Espíndola wrote:>> @a = unnamed constant i32 0 @b = unnamed constant float 0.0 >> >> This can be done today, and then the type system change won't affect >> constant merging. > > It is true that it is better to have passes know that different types > can have the same bits, but a type merging pass would still be useful > for the passes that have not been updated or just for reducing the size > of a bitcode file. > > The main question is if such a pass would be legal, or if we would > guarantee that Foo and Bar in the above examples would remain as two > different types.It would be legal. Type names have no semantic effect on the program. They aren't tied to TBAA or anything like that. -Chris