This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: patch to canonize unsigned tree-csts

I was hoping Richard would weigh in here.  In case not...

Kenneth Zadeck <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]