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*: Ian Lance Taylor <iant at google dot com>*To*: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)*Cc*: ebotcazou at adacore dot com, gcc-patches at gcc dot gnu dot org, matz at suse dot de, richard dot guenther at gmail dot com*Date*: 01 Oct 2007 12:49:53 -0700*Subject*: Re: [PATCH] Fix optimization regression in constant folder*References*: <200709171539.26653.ebotcazou@adacore.com> <200710010127.59677.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> <84fc9c000710010212q3c28f27do3c665c87c6089bc9@mail.gmail.com> <10710011233.AA10135@vlsi1.ultra.nyu.edu> <84fc9c000710010540o7d648f21q4fd19df493629b26@mail.gmail.com> <10710011319.AA12088@vlsi1.ultra.nyu.edu> <m3ve9q207p.fsf@localhost.localdomain> <10710011934.AA24578@vlsi1.ultra.nyu.edu>

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes: > > TYPE_OVERFLOW_WRAPS seems clearly correct for sizetypes (if not, why > > not, and give us an example). > > For the reason you just gave: it suppresses some optimizations. It doesn't, though. Having TYPE_OVERFLOW_WRAPS be true for a type does not cause gcc to avoid any optimizations. (Not having TYPE_OVERFLOW_UNDEFINED be true does avoid optimizations; having TYPE_OVERFLOW_WRAPS be true does not.) > > I really want to move toward a semantics for sizetypes which does not > > involve mysterious checks for TYPE_IS_SIZETYPE. If we can't do that, > > we are going to keep breaking the way you want it to work. > > I see it exactly the opposite way around: sizetype means "handle this > computations in the most efficient way possible" (like my EXACT_DIV_EXPR). > So any optimization conditionalized on an attribute of the type can simply > can "|| TYPE_IS_SIZETYPE". But if we go the approach of defining flags in > a special way to deal with case and then get rid of TYPE_IS_SIZETYPE, we > have to go through exactly the same problem as now if some other > attributes are added to types that suppress only some optimizations. I think that approach winds up being confusing. We have to think about types in terms of what operations are permitted on them. Ian

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

**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:*Richard Guenther

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

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

**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:*Richard Kenner

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

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