Hi Andrew, > Does it make sense rather to do the non-merge based on the mode in the > case of floating point with maybe a target hook that > mergeable_constant_section calls? > I don't think a param is a good approach here rather than something > finer control.
That's a good point - I was using these params for experimentation, and while they are quite useful for that, there are existing hooks that allow selection based on the mode. > For an example an constant array of 4 char would still be size of 4 > but do you still want to merge those constants or use anchors in that > case? Or is it just floating point values where it might improve > things? If it's an array then it cannot be merged. Switch statements using offset tables may be mergeable, but it's not clear how useful this is since it would be pure chance that they match and can be merged. > Note I am trying to convince myself which way is better because right > now it is not obvious from this patch if something finer tuned is > needed or doing it by size is always a good idea. > Maybe there are not many non-floating point constants that go into the > mergeable section so the size check won't make a huge difference in > the end; I know that the constant switch load table is now a mergeable > decl. But maybe that does not show up enough to make a difference > here. Likewise of the backing constant of a std::initializer_list. > I would rather be forward looking on this and add the hook now rather > than later on when there are much more mergeable constants which we > want to still merge. I think I will use the existing hooks for this - once we've got the optimal setting, there is less need to change the value from the command-line. So consider this patch withdrawn. Cheers, Wilco
