This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix optimization regression in constant folder
> It matches undefined overflow && wrapping overflow, as for infinite precision
> overflow really cannot happen.
But it can happen: in the case of illegal programs when the programmer tries
to make an object that's too big.
> You say you need special semantics because otherwise optimization won't work.
Actually, I didn't say that. I said that sizetypes *already have* and
always have had different semantics than user-visible types and that trying
to map those semantics onto a new set of semantics being defined for
user-visible types is not correct.
> This needs testcases.
Eric and I have both given you an example of an optimization that should
apply to sizetypes but which won't if you try to change their semantics to
match those of a user-visible type.
> Otherwise just mapping sizetype semantics to an _existing_ semantic makes
> most sense as it reduces diversity of semantics and causes less
I'm not proposing changing the semantics of sizetypes! Quite the contrary:
I'm saying that we keep them as they are and *not* try to map them to these
new flags which are meant for user-visible types.
> Look at all the places we _don't_ specialize sizetypes! You want to audit
> all these?
I don't follow. All these optimizations used to be done for sizetypes and
I'm saying they need to continue to work. It's the proposal to use these
new flags that's changing things. And I also don't understand what "audit"
means in this context. The semantics of these various types (sizetypes and
the different user-visible type semantics) only differ in overflow
handling. So we only need to "audit" those cases where overflow tests are
A good analogy to sizetypes are EXACT_DIV_EXPR. That doesn't correspond to
any user-visible construct but is used in the compiler when we know that
the division will have an exact result and we don't have to worry about
special cases for the remainder. You can ask (definitionally, at least)
which of the other rounding types it's equivalent to and the answer is that
it's not equivalent to *any* of them because the compiler is free to
generate, in a case-by-case manner, whatever code is more efficient knowing
that it doesn't have to worry about remainder semantics.
It's the same for sizetypes. We're not making them equivalent to any other
type of overflow behavior, but instead saying that, in each case, the
compiler is free to generate the best code it can for them knowing that it
doesn't have to worry about overflow semantics concerns.
This is not a new definition: sizetypes have *always* been defined this
way. We just never needed to specify this as part of their definition
Note that I'm the one who added TYPE_IS_SIZETYPE flag back in 2000 and made
the concept of treating sizetypes specially so I know what my intent was
then. Indeed there was no documentation then about the overflow issue
because nobody was thinking in those terms at that point.
What you're proposing to do is to *change* the semantics of sizetypes from
those in 2000 to match that of some variant of flags that can be specified
on user-visible types. That proposal would need some evidence that it's
beneficial to do that.
But Eric's patch that started this thread is just implementing the
*present* definition of sizetypes. stage3 is not the appropriate time to
change the semantics of something, so his patch seems appropriate to me.