I was hoping Richard would weigh in here. In case not... Kenneth Zadeck <zad...@naturalbridge.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. Thanks, Richard
