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] Fix optimization regression in constant folder

> Right.  I don't think it's important per se whether or not we have a
> TYPE_IS_SIZETYPE flag or not.  But, I do think it's important that we
> define the semantics of sizetypes, if we're going to use them.


> Kenner, perhaps you could define the semantics as differences from an
> ordinary integer type?  "A sizetype is like an ordinary INTEGER_TYPE,
> except that ..."?

The problem is that all I can do now is offer an *operational* definition,
so it would be "... except that all the operations on it are generated by
the compiler as part of computations of sizes and offsets so that we can
prove certain properties of those expressions that would not be true for
integer types in more general usages".

Yes, it might be nice to enumerate that list of properties, but I don't see
it as critical that we do so, since instead we can just ask the question
for each case (optimization) that comes up.  For each such, either we feel
we can make the proof, meaning the optimization is safe, or we can't make
the proof, meaning it isn't safe.  For a first approximation, we can
certainly say that if the optimization is safe assuming a wrapping
semantics than it's safe for sizetypes.  But we also know that the converse
is NOT true and there may be some individual transformations that we know
ARE safe for sizetypes (e.g, the (a*c1)/c2 example) even though they aren't
true for general integer types that wrap. 

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