This is the mail archive of the gcc-patches@gcc.gnu.org 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


On 10/11/07, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote:
> > So I propose to define all sizetypes as having undefined overflow (the same
> > as for pointers) as this will likely cause the least problems with mismatched
> > semantics of involved types in expressions.  If we do that we should see the
> > optimization issues in C as well.
>
> No you won't because people don't use variable-length arrays in C that much:
> it's rare to see them *at all*.  But it's not at all uncomon in real Ada
> code to have a dozen or more variable-length arrays in a single record.
>
> But I also don't understand why pointers and sizetypes should have anything
> like similar properties.  Sizetypes talk about sizes and offsets and
> pointers talk about addresses: those seem very different to me.
>
> As a pragmatic matter, the reason you want pointers to have undefined
> overflow semantics are so that you don't lose loop optimizations when pointers
> are used as bivs, which is very common while computations involving the
> addition and subtraction of pointers don't get very complicated.

Yes.

> It's exactly the other way around for sizetypes: they aren't bivs, so
> there's no advantage in having undefined overflow semantics, but they ARE
> used in complex computations, where having wrapping semantics will allow
> better optimizations.

The problem I see is that we mix pointers and sizetype variables and in that
way effectively have both, undefined overflow and wrapping which will likely
cause problems.  Of course these problems would exist right now, so maybe
they do not happen, or at least they happen very seldom and don't yet cause
miscompilations.

Richard.


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