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


> So, in particular, when you pass (0, 0xffffffff) to fit_double_type,
> using an unsigned sizetype as a the type, you end up with (0xffffffff,
> 0xffffffff) as your representation, assuming 32-bit HOST_WIDE_INT and
> 32-bit sizetype. 

I wasn't aware we do that and it seems peculiar to me.  I doubt it matters
either way how we handle that, though.

> 3. Unsigned sizetypes are treated as if TYPE_OVERFLOW_UNDEFINED (i.e.,
> as if they were signed) was defined in the case of multiply/division
> that cancel.  (See extract_muldiv_1.)

In that case, yes, but treated as if overflow wraps for the other case
(the association cases).

> I'm not sure how sizetype is a win over representing sizes as size_t,
> differences between sizes as ptrdiff_t, and performing operations on
> sizes by first doing a bit-preserving cast from size_t to ptrdiff_t,
> then doing all the operations on ptrdiff_t, and then casting back if
> necessary.

Because size_t, being user-visible, has to have a consistent view of
the handling of overflow (whether it's defined or wraps) and sizetypes
don't and the latter allows more optimizations.  As to conversions, I
don't see much code that computes the difference between sizes (indeed I
can't think of any such at the moment), so I can't really comment on
it, but I do worry about adding too many conversions for lots of reasons.


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