Hello, Tatu> Is that correct? I think it's just something to be aware of.Currently we're aggressively merging globals by default. Do you think it will be better to provide special flag to control this behavior? -- WBR, Anton Korobeynikov
On Oct 17, 2008, at 7:30 AM, Anton Korobeynikov wrote:> Hello, Tatu > >> Is that correct? I think it's just something to be aware of. > Currently we're aggressively merging globals by default. Do you > think it > will be better to provide special flag to control this behavior?Please no flag. If we want to fix this problem, lets do it right. To me this consists of some flag on GlobalVariable that says that it is 'mergable' or something like that. Then -constmerge would be changed to only merge globals with this flag on it, or globals that are provably not "address exposed" (which could be modeled by having the optimizer set the bit). We'd also have to change the code generator to stop sending these globals into the various sections that the linker merges. It is important to model this so that we don't lose string merging. We need to distinguish between the string globals in these two cases: char x[] = "foo"; char *y = "foo"; Both will end up with a 4 byte string global variable in LLVM IR, but only one of those is mergable. -Chris
On 17.10.2008, at 17.30, Anton Korobeynikov wrote: Hi Anton,> Currently we're aggressively merging globals by default. Do you > think it > will be better to provide special flag to control this behavior?I think that (once again from the user POV) the "Principle of Least Surprise" should apply here - meaning that this behavior should never be on by default. It is interesting that in GCC documentation for -fmerge-all-constants you find this: "Languages like C or C++ require each non-automatic variable to have distinct location, so using this option will result in non-conforming behavior." --- Tatu Vaajalahti Tampere, Finland
On 17/10/2008, Chris Lattner <clattner at apple.com> wrote:> Please no flag. If we want to fix this problem, lets do it right. To > me this consists of some flag on GlobalVariable that says that it is > 'mergable' or something like that.Wouldn't it be slightly cleaner to mark the distinct objects in the LLVM intermediate representation? This would make the default case the one resulting in best code, and seems to me to follow the principle of structural equivalence of types (and values) used elsewhere. -- Dan Villiom Podlaski Christiansen, stud.scient. danchr at daimi.au.dk, danchr at gmail.com