This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Revisiting the TYPE_IS_SIZETYPE issue
On Tue, May 27, 2008 at 10:37 AM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> I think that rather than trying to special case sizetype again too much
>> we should try to sort out a plan on how to move the
>> TYPE_OVERFLOW_WRAPS and TYPE_OVERFLOW_UNDEFINED
>> semantics away from types down to the operators - which is needed
>> anyway for LTO of TUs with different setting of -fwrapv for example.
>> This would also allow passes like VRP to keep which expressions
>> may overflow and thus enable further optimizations.
>>
>> Rather than the two flags TYPE_OVERFLOW_WRAPS and
>> TYPE_OVERFLOW_UNDEFINED we should make it more explicit
>> (and conveniently match intended sizetype behavior) and distinguish
>> between operations that may overflow and operations that we know
>> do not ('does not overflow' is a valid interpretation of 'undefined
>> overflow').
>
> I think it depends on what "we know do not" means. If this is a property that
> needs to be preserved, it's no different from the current situation since it
> will also prevent reassociation.
>
> But, more fundamentally, you seem to be still proposing a binary world, i.e
> "may overflow" for C unsigned semantics and "does not overflow" for C signed
> semantics. How would the TYPE_IS_SIZETYPE semantics fit exactly? It cannot
> be reduced to either of the above 2 so you need either a third state or to
> have parameterizable transition rules between the 2 states.
Well, this goes back to the question what TYPE_IS_SIZETYPE semantics
are ;) I guess it would be a sort-of "sticky" 'does not overflow'
flag? That is
even after any possible re-association no operation does overflow? What
happens if you re-associate (A +/o B) +/s C (the first +/o might overflow,
the second +/s is the "sticky" one)?
>From the past discussion we are still waiting for a testcase where the
reassoication in question (the one that initially provoked all these
discussions) matters.
IMHO it's not worth keeping TYPE_IS_SIZETYPE semantics. But I
repeatedly said that.
>> So my idea (I have this for some time now, but there's always lack
>> of time to implement it ...) is to make the existing tree codes
>> 'may overflow' operations and introduce new tree code variants
>> with the 'does not overflow' semantics. This way we conservatively
>> preserve 'may overflow' in legacy code.
>>
>> The middle-end would then _never_ look at the types to determine
>> overflow behavior, but only at the properties of the operands involved.
>
> OK, I think that this would be a net improvement over what we have now but its
> interaction with the TYPE_IS_SIZETYPE semantics is still a bit unclear to me.
Re-association is always possible with my idea - you just need to drop from
'does not overflow' to 'may overflow' operations (thus in C speak, from
signed overflow semantics to unsigned overflow semantics) for the
expression in question. IMHO this should allow all optimizations you
want from TYPE_IS_SIZETYPE types without actually having them.
Richard.