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

On 14 Oct 2007 08:45:53 -0700, Ian Lance Taylor <> wrote:
> "Richard Guenther" <> writes:
> > On 10/14/07, Eric Botcazou <> wrote:
> > > > The flags aren't fixed in stone.  In fact, I just introduced them
> > > > earlier this year.  So all this tells me is that we need to change the
> > > > flags.  I already proposed such a change
> > > > (  Nobody has
> > > > yet explained why my proposal wouldn't work.
> > >
> > > From my point of view, your proposal (TYPE_IGNORE_OVERFLOWS +
> >
> > I don't want to have TYPE_IGNORE_OVERFLOWS.  Matters are complicated
> > enough already.  I also like you to revisit the decision to make Ada sizetype
> > signed.  If there are optimization regressions for expressions created by
> > stor-layout.c solve them there, as that is the place where enough knowledge
> > about the involved magnitudes is available.
> The point of TYPE_IGNORE_OVERFLOWS is not for signed vs. unsigned, but
> is rather to permit retaining the optimization currently done for
> TYPE_IS_SIZE_TYPE in extract_muldiv_1.
>          If we have an unsigned type that is not a sizetype, we cannot do
>          this since it will change the result if the original computation
>          overflowed.
> We don't want to set TYPE_OVERFLOW_UNDEFINED for sizetypes, because we
> want to overflow to wrap, and in particular because we want to permit
> reassociation.  We need some way to indicate that this type does not
> overflow.

In which case sizetypes semantics are that of an infinite precision
integral type.  In which case an always signed sizetype makes sense.

Of course I don't believe in infinite precision for sizetype as it only
has the precision of pointers [so we'd truncate integer constants too
eagerly].  It looks like giving sizetype mode_for_size (GET_MODE_SIZE
(Pmode)) (or similar) while raising its precision to cover the full
2 * HWI could do the right thing for constants and expansion.  Supposed
that we only ever expand to things that do not overflow - but this is
what Kenner and friends insist on anyway.

Still I don't like at all that sizetype is a frontend-specific type.  Still
I don't like that sign-extension is somehow special for sizetypes.  Still
I will be not the one to audit optimizations if they will go wrong on
sizetypes because they ask for the wrong properties of the types involved.

Why not take the opportunity to clean up the current stuff a bit before
introducing more [lacking a proper noun]?


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