This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: patch to fix
On Wed, 3 Oct 2012, Mike Stump wrote:
On Oct 3, 2012, at 1:47 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
did you consider making the size of wide_int a template parameter, now
that we are using C++? All with a convenient typedef or macro so it
doesn't show. I am asking because in vrp I do some arithmetic that
requires 2*N+1 bits where N is the size of double_int.
No, not really. I'd maybe answer it this way, we put in a type
(singular) to support all integral constants in all languages on a port.
Since we only needed 1, there was little need to templatize it. By
supporting all integral constants in all languages, there is little need
for more. If Ada say, wanted a 2048 bit integer, then, we just have it
drop off the size it wants someplace and we would mix that in on a
MAX(â.) line, net result, the type we use would then directly support
the needs of Ada. If vpr wanted 2x of all existing modes, we could
simply change the MAX equation and essentially double it; if people need
that. This comes as a cost, as the intermediate wide values are fixed
size allocated (not variable); so these all would be larger.
And this cost could be eliminated by having a template wide_int_ so only
the places that need it actually use the extra size ;-)
On Wed, 3 Oct 2012, Kenneth Zadeck wrote:
i have already converted the vrp code, so i have some guess at where you are
talking about. (of course correct me if i am wrong).
in the code that computes the range when two variables are multiplied
together needs to do a multiplication that produces a result that is twice as
wide as the inputs.
Yes, exactly.
my library is able to do that with one catch (and this is a big catch): the
target has to have an integer mode that is twice as big as the mode of the
operands. The issue is that wide-ints actually carry around the mode of the
value in order to get the bitsize and precision of the operands (it does not
have the type, because this code has to both work on the rtl and tree level
and i generally do not want the signness anyway).
my current code in vrp checks to see if such a mode exists and if it does, it
produces the product. if the mode does not exist, it returns bottom. What
this means is that for most (many or some) targets that have a TImode, the
largest thing that particular vrp discover ranges for is a DImode value. We
could get around this by defining the next larger mode than what the target
really needs but i wonder how much mileage you are going to get out of that
with really large numbers.
This will be for discussion when you submit that next patch, but currently
VRP handles integers the same size as double_int. In particular, it
handles __int128. I would be unhappy if introducing a larger bigint type
in gcc made us regress there.
--
Marc Glisse