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 10:48:43 -0700*Subject*: Re: [PATCH] Fix optimization regression in constant folder*References*: <200709171539.26653.ebotcazou@adacore.com> <10710010257.AA21585@vlsi1.ultra.nyu.edu> <Pine.LNX.4.64.0710010454060.23011@wotan.suse.de> <10710010344.AA22633@vlsi1.ultra.nyu.edu> <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>

Richard Kenner wrote: > 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. I don't think that's good enough. If we can't specify this better, then I suspect that, over time, it's going to break, and people will eventually just rip it out. So far, we've got no test cases and no explanation of the semantics. So, I don't think you should be surprised if the middle-end maintainers decide they don't understand the point and replace it with, essentially, the user-level size_t. That's going to hurt Ada hardest because in C/C++, there aren't very many run-time computations involving sizes; most of what we do with sizes is folded away at compile-time, or is converted from sizetype to the user-level size_t anyhow. (For example, calling an inline C++ new operator converts to size_t before doing the inlining, so any computations on the size done within the body of the operator are going to be done on the user-level type, and optimization limitations that apply to ordinary unsigned integer types will end up applying here too.) The only place I can actually see uses of TYPE_IS_SIZETYPE are fold-const.c and tree.c. And, in both cases, it looks like we do exactly one thing: treat sizetypes are sign-extended even when TYPE_UNSIGNED. That begs the question: why aren't they signed, or why do we care about bits outside their precision? Where are the extra optimizations happening that you're talking about? -- 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:*Eric Botcazou

**References**:**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:*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

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

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