This is the mail archive of the
mailing list for the GCC project.
Re: patch to canonize unsigned tree-csts
- From: Kenneth Zadeck <zadeck at naturalbridge dot com>
- To: Richard Biener <rguenther at suse dot de>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Mike Stump <mikestump at comcast dot net>, rdsandiford at googlemail dot com
- Date: Thu, 03 Oct 2013 12:47:11 -0400
- Subject: Re: patch to canonize unsigned tree-csts
- 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> <87hacytjmm dot fsf at talisman dot default>
you miss the second reason why we needed addr-wide-int. A large amount
of the places where the addressing arithmetic is done are not "type
safe". Only the gimple and rtl that is translated from the source
code is really type safe. In passes like the strength reduction
where they just "grab things from all over", the addr-wide-int or the
max-wide-int are safe haven structures that are guaranteed to be large
enough to not matter. So what i fear here is something like a very
wide loop counter being grabbed into some address calculation.
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
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.