On 10/07/2012 09:19 AM, Richard Guenther wrote:
>In fact, you could argue that the tree level did it wrong (not that i am
>suggesting to change this). But it makes me think what was going on when
>the decision to make TYPE_PRECISION be an INT_CST rather than just a HWI was
>made. For that there is an implication that it could never take more than
>a HWI since no place in the code even checks TREE_INT_CST_HIGH for these.
Well - on the tree level we now always have two HWIs for all INTEGER_CSTs. If
we can, based on the size of the underlying mode, reduce that to one
HWI we already
win something. If we add an explicit length to allow a smaller
encoding for larger modes
(tree_base conveniently has an available 'int' for this ...) then we'd
win in more cases.
Thus, is CONST_INT really necessarily better than optimized CONST_WIDE_INT
storage?
i have to admit, that looking at these data structures gives me a
headache. This all looks like something that Rube Goldberg would have
invented had he done object oriented design (Richard S did not know who
Rube Goldberg when i mentioned this name to him a few years ago since
this is an American thing, but the british had their own equivalent and
I assume the germans do too.).
i did the first cut of changing the rtl level structure and Richard S
threw up on it and suggested what is there now, which happily (for me) i
was able to get mike to implement.
mike also did the tree level version of the data structures for me. i
will make sure he used that left over length field.
The bottom line is that you most likely just save the length, but that
is a big percent of something this small. Both of rtl ints have a mode,
so if we can make that change later, it will be space neutral.
