This is the mail archive of the
mailing list for the GCC project.
Re: patch to canonize unsigned tree-csts
- From: Richard Sandiford <rsandifo at linux dot vnet dot ibm 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: Fri, 04 Oct 2013 18:00:34 +0100
- 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> <524D9F8F dot 7080808 at naturalbridge dot com>
I was hoping Richard would weigh in here. In case not...
Kenneth Zadeck <email@example.com> writes:
>>>> 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.
> 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.
It still seems really dangerous to be implicitly truncating a wider type
to addr_wide_int. It's not something we'd ever do in mainline, because
uses of addr_wide_int are replacing uses of double_int, and double_int
is our current maximum-width representation.
Using addr_wide_int rather than max_wide_int is an optimisation.
IMO part of implementating that optimisation should be to introduce
explicit truncations whenever we try to use addr_wide_int to operate
on inputs than might be wider than addr_wide_int.
So I still think the assert is the way to go.