https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #34 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- Excellent ideas! For that matter, we may get away with defaulting to 3 sub-ranges and always resizing as needed (up to MAX). Needing more than 3 sub-ranges is so rare (less than 0.5% of the time), that the penalty will be small. Furthermore, these defaults are sensible enough that we could nuke int_range<N> altogether and have irange have this small [3*2] array. After all, most uses of int_range<N> now are int_range_max, since we never know the size of the range (except in rare cases such as boolean_type_node, etc). This would simplify the code and get rid of the annoying templates which I hate. No need for int_range_max, or int_range<N>, etc. Just plain irange. This would give us an irange of 592 bytes compared to 40912 for int_range_max currently. Plus, it's not that far away from int_range<2> which currently is 432 bytes, and as I mentioned, barely happens as we mostly use int_range_max. I think this is a nice trade off. Cleaner more flexible code, without templates. Oh... preliminary tests show it's a 5% penalty for VRP, which is more than covered by our 13.22% improvement (plus Andrew's cache improvements) to VRP.
