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] |

*From*: Mark Mitchell <mark at codesourcery dot com>*To*: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>*Cc*: ebotcazou at adacore dot com, gcc-patches at gcc dot gnu dot org, iant at google dot com, matz at suse dot de, richard dot guenther at gmail dot com*Date*: Fri, 12 Oct 2007 11:37:05 -0700*Subject*: Re: [PATCH] Fix optimization regression in constant folder*References*: <200709171539.26653.ebotcazou@adacore.com> <470D0C50.4080506@codesourcery.com> <Pine.LNX.4.64.0710111658530.23011@wotan.suse.de> <10710111536.AA24058@vlsi1.ultra.nyu.edu> <Pine.LNX.4.64.0710111756080.23011@wotan.suse.de> <10710111616.AA25194@vlsi1.ultra.nyu.edu> <Pine.LNX.4.64.0710111828400.23011@wotan.suse.de> <10710111651.AA26098@vlsi1.ultra.nyu.edu> <Pine.LNX.4.64.0710111853060.23011@wotan.suse.de> <m3r6k13728.fsf@localhost.localdomain> <Pine.LNX.4.64.0710112011530.23011@wotan.suse.de> <10710111850.AA27 912@vlsi1.ultra.nyu.edu> <Pine.LNX.4.64.0710112057570.2 <m3ve9d1h27.fsf@localhost.localdomain> <10710120240.AA03734@vlsi1.ultra.nyu.edu> <m3wsttymh6.fsf@localhost.localdomain> <470EFE64.6070204@codesourcery.com> <10710121235.AA10499@vlsi1.ultra.nyu.edu> <470FB37B.9040904@codesourcery.com> <10710121812.AA17868@vlsi1.ultra.nyu.edu>

Richard Kenner wrote: >> That begs the question: why aren't they signed > > I think because you run into problems in corner cases in C if size_t and > sizetype don't have the same precision and signedness or, more precisely, > if you can't encode a value that's a valid result of size_t in sizetype. That's why C has size_t and ptrdiff_t. I'd expect that DECL_SIZE and friends to have an unsigned sizetype. I'd expect things like the difference between two field offsets to have a signed sizetype. Obviously, if we need to represent all possible differences, then you need a wider type than sizetype to represent that -- just as ptrdiff_t cannot represent all possible differences between pointers in C. In any case, I think we've just about answered what the semantics of the current sizetype are: 1. Unsigned sizetypes are sign-extended, as if they were signed. (See fit_double_type.) 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. Other checks seem to be consequences of that; you cannot make certain assumptions about widening, you can ignore the sign-extended bits when doing host_integerp, etc. 2. TREE_OVERFLOW is set for operations that overflow on an unsigned sizetype, as if they were signed. (See int_const_binop.) 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.) I don't think we know the *why* for (1) and (2) at this point. We do have a justification for (3); this is your claim that when we generate these combinations we mean to allow reassociation. 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. -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713

**Follow-Ups**:**Re: [PATCH] Fix optimization regression in constant folder***From:*Richard Kenner

**Re: [PATCH] Fix optimization regression in constant folder***From:*Richard Guenther

**References**:**Re: [PATCH] Fix optimization regression in constant folder***From:*Mark Mitchell

**Re: [PATCH] Fix optimization regression in constant folder***From:*Michael Matz

**Re: [PATCH] Fix optimization regression in constant folder***From:*Richard Kenner

**Re: [PATCH] Fix optimization regression in constant folder***From:*Michael Matz

**Re: [PATCH] Fix optimization regression in constant folder***From:*Richard Kenner

**Re: [PATCH] Fix optimization regression in constant folder***From:*Michael Matz

**Re: [PATCH] Fix optimization regression in constant folder***From:*Richard Kenner

**Re: [PATCH] Fix optimization regression in constant folder***From:*Michael Matz

**Re: [PATCH] Fix optimization regression in constant folder***From:*Ian Lance Taylor

**Re: [PATCH] Fix optimization regression in constant folder***From:*Michael Matz

**Re: [PATCH] Fix optimization regression in constant folder***From:*Ian Lance Taylor

**Re: [PATCH] Fix optimization regression in constant folder***From:*Richard Kenner

**Re: [PATCH] Fix optimization regression in constant folder***From:*Ian Lance Taylor

**Re: [PATCH] Fix optimization regression in constant folder***From:*Mark Mitchell

**Re: [PATCH] Fix optimization regression in constant folder***From:*Richard Kenner

**Re: [PATCH] Fix optimization regression in constant folder***From:*Mark Mitchell

**Re: [PATCH] Fix optimization regression in constant folder***From:*Richard Kenner

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |