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*: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)*To*: mark at codesourcery dot com*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 08:35:00 EDT*Subject*: Re: [PATCH] Fix optimization regression in constant folder*References*: <200709171539.26653.ebotcazou@adacore.com> <m3abr33dbp.fsf@localhost.localdomain> <10710010056.AA15609@vlsi1.ultra.nyu.edu> <Pine.LNX.4.64.0710010325340.23011@wotan.suse.de> <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>

> Right. I don't think it's important per se whether or not we have a > TYPE_IS_SIZETYPE flag or not. But, I do think it's important that we > define the semantics of sizetypes, if we're going to use them. Agreed. > Kenner, perhaps you could define the semantics as differences from an > ordinary integer type? "A sizetype is like an ordinary INTEGER_TYPE, > except that ..."? 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. For each such, either we feel we can make the proof, meaning the optimization is safe, or we can't make the proof, meaning it isn't safe. For a first approximation, we can certainly say that if the optimization is safe assuming a wrapping semantics than it's safe for sizetypes. But we also know that the converse is NOT true and there may be some individual transformations that we know ARE safe for sizetypes (e.g, the (a*c1)/c2 example) even though they aren't true for general integer types that wrap.

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

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

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

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