Kenneth Zadeck <zad...@naturalbridge.com> writes: > I would like you to respond to at least point 1 of this email. In it > there is code from the rtl level that was written twice, once for the > case when the size of the mode is less than the size of a HWI and once > for the case where the size of the mode is less that 2 HWIs. > > my patch changes this to one instance of the code that works no matter > how large the data passed to it is. > > you have made a specific requirement for wide int to be a template that > can be instantiated in several sizes, one for 1 HWI, one for 2 HWI. I > would like to know how this particular fragment is to be rewritten in > this model? It seems that I would have to retain the structure where > there is one version of the code for each size that the template is > instantiated.
I think richi's argument was that wide_int should be split into two. There should be a "bare-metal" class that just has a length and HWIs, and the main wide_int class should be an extension on top of that that does things to a bit precision instead. Presumably with some template magic so that the length (number of HWIs) is a constant for: typedef foo<2> double_int; and a variable for wide_int (because in wide_int the length would be the number of significant HWIs rather than the size of the underlying array). wide_int would also record the precision and apply it after the full HWI operation. So the wide_int class would still provide "as wide as we need" arithmetic, as in your rtl patch. I don't think he was objecting to that. As is probably obvious, I don't agree FWIW. It seems like an unnecessary complication without any clear use. Especially since the number of significant HWIs in a wide_int isn't always going to be the same for both operands to a binary operation, and it's not clear to me whether that should be handled in the base class or wide_int. Richard
