On Thu, May 25, 2017 at 5:05 PM, Mike Stump <mikest...@comcast.net> wrote: > On May 24, 2017, at 1:25 AM, Richard Biener <richard.guent...@gmail.com> > wrote: >> >> There's trailing_wide_ints. But having 6 of them is still expensive. >> >> Something nice would be to make wide_ints not tied to use HOST_WIDE_INT >> as basic element type but for example uint32. > > wide_int was made so that they would be calculation time efficient at the > expense of a little space efficiency. The underlying type is fairly > arbitrary, and indeed, one could add it as a template parameter, and have all > the existing code just use HWI for that parameter. The new space saving > version, could pass char, or short, or int, if they wanted to. The only down > side should be an extreme slowdown on operations. It would be a lot of work > to do this... but thought I would mention it. Earlier on, we used int for > testing to ensure that the code was solid, as when using a 64-bit chunk, most > code never needs more than 1. With a 32-bit type, the odds of more than 1 > being used spike up considerably. >
Yes. I think my original argument was that with 64bits the code path for >1 element get not very much coverage. The most difficulties will be generalizing all those HWI using interfaces in the API... Richard.
