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*: "Richard Guenther" <richard dot guenther at gmail dot com>*To*: "Richard Kenner" <kenner at vlsi1 dot ultra dot nyu dot edu>*Cc*: matz at suse dot de, ebotcazou at adacore dot com, gcc-patches at gcc dot gnu dot org, iant at google dot com, mark at codesourcery dot com*Date*: Thu, 11 Oct 2007 19:06:32 +0200*Subject*: Re: [PATCH] Fix optimization regression in constant folder*References*: <200709171539.26653.ebotcazou@adacore.com> <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> <10710111621.AA25372@vlsi1.ultra.nyu.edu> <Pine.LNX.4.64.0710111840360.23011@wotan.suse.de> <10710111701.AA26308@vlsi1.ultra.nyu.edu>

On 10/11/07, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote: > > Yes I understand that. But what we have to do in the middle-end from C++ > > constructs like Mark has shown has to be done in a type which does not > > have the ignore_overflow "semantic" (because the justification for that > > semantic, namely negative values have small magnitude simply doesn't > > hold). In fact the most natural choice for a type to calculate that > > expression would have been unsigned because that allows all rearrangements > > of the operands. But when the natural type for doing arithmetics on such > > operands is type X it simply doesn't make sense to store those operands as > > having type Y, as conversions would be required all the time we actually > > look at the operands. > > But I thought that we agreed yesterday that, unless there are some surprises > coming from givs in loop optimization, we should treat sizetypes as > wrapping on overflow, whether signed or unsigned. So I'm not sure what you > mean above. > > Certainly the point is to do the entire sizing computation in ONE type > and not convert back and forth: that's the whole point of sizetype! Yes - one excercise we should carry out is to put in place some checks that we only convert _to_ sizetype, but never _from_ it. The only place we go "backward" is using POINTER_PLUS_EXPR which doesn't require an explicit conversion. Of course there might be optimization passes that propagate the offset from POINTER_PLUS_EXPR in interesting ways back to user-visible integer types - think of &a[i] - &a[j] which we even fold to i - j (of user integer type, that is). So I don't really think such a check is practical. Richard.

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

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

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

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