This is the mail archive of the
mailing list for the GCC project.
Re: patch to canonize small wide-ints.
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Kenneth Zadeck <zadeck at naturalbridge dot com>
- Cc: Richard Biener <rguenther at suse dot de>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Mike Stump <mikestump at comcast dot net>
- Date: Thu, 03 Oct 2013 17:16:33 +0100
- Subject: Re: patch to canonize small wide-ints.
- Authentication-results: sourceware.org; auth=none
- References: <5238B585 dot 2020703 at naturalbridge dot com> <alpine dot LNX dot 2 dot 00 dot 1309241539100 dot 29411 at zhemvz dot fhfr dot qr> <5241986B dot 7040306 at naturalbridge dot com> <alpine dot LNX dot 2 dot 00 dot 1309241550270 dot 29411 at zhemvz dot fhfr dot qr> <524D7A13 dot 6060303 at naturalbridge dot com> <871u42e8c7 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <524D8465 dot 8000301 at naturalbridge dot com>
Kenneth Zadeck <email@example.com> writes:
>> Changing the representation of unsigned constants is only worthwhile
>> if we can avoid the force_to_size for some unsigned cases. I think we can
>> avoid it for precision >= xprecision && !small_prec. Either we should take
>> the hit of doing that comparison (but see below) or the change isn't
> i think that it is something closer to precision >= xprecision +
> HOST_BITS_PER_WIDE_INT && ...
> The problem is that the tree cst may have one extra block beyond the
>> I was thinking that we should always be able to use the constant as-is
>> for max_wide_int-based and addr_wide_int-based operations. The small_prec
> again, you can get edge cased to death here. i think it would work
> for max because that really is bigger than anything else, but it is
> possible (though unlikely) to have something big converted to an address
> by truncation.
But I'd have expected that conversion to be represented by an explicit
CONVERT_EXPR or NOP_EXPR. It seems wrong to use addr_wide_int directly on
something that isn't bit- or byte-address-sized. It'd be the C equivalent
of int + long -> int rather than the expected int + long -> long.
Same goes for wide_int. If we're doing arithmetic at a specific
precision, it seems odd for one of the inputs to be wider and yet
not have an explicit truncation.