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*: Michael Matz <matz at suse dot de>*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, mark at codesourcery dot com, richard dot guenther at gmail dot com*Date*: Thu, 11 Oct 2007 19:04:08 +0200 (CEST)*Subject*: Re: [PATCH] Fix optimization regression in constant folder*References*: <200709171539.26653.ebotcazou@adacore.com> <200709301801.39718.ebotcazou@adacore.com> <m3r6kf3gyx.fsf@localhost.localdomain> <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> <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>

Hi, On Thu, 11 Oct 2007, Richard Kenner wrote: > > "these properties" are those which you and Eric expected sizetype to have, > > and where we then had this very thread to actually try and spell out the > > properties, i.e. those properties which you initially "defined" as "all > > optimizations are allowed". > > One can argue about what those properties ought to be, but they clearly > have *some* properties! Of course. I think "unsigned, wrapping overflow" are these properties, hence no need for a special sizetypiness. > And there's no particular reason to believe those should match those of > any user-visible type, since they are used in very different ways than > any user-visible type. Please, don't go that route again. I'm not talking about user-visible types. I never was. I'm talking about the properties of sizetype (the global tree node), and I'm arguing that it simply should be an unsigned integer type without other special properties. Don't repeat the argument of Ada needing negative values there, I think it's a red herring as negative values can be represented in unsigned types just fine, it's just a matter of interpreting it correctly. > Being able to *show* a test case and *having* one aren't the same! The > problem here is that it's only going to occur in large programs and > those are proprietary. It's a lot of work to sanitize such a large test > case. Conceptually, it's easy to describe: we're talking about records > where there are a large number of variable-length arrays, some of which > have the same index and some of which do not, and we're trying to > simplify the computation of the offset of the later fields ni the > record. Okay, so conceptually it's like: struct S { int a1[n1*n2]; int a2[n2*n1]; int a3[n3]; } s; /* so a1 and a2 have the same number of elements */ And then you access this in e.g. such way: for (i = start; i <= end; i++) use (s.a1[i], s.a2[i+2], s.a3[i]); And you of course want that the necessary index calculations are done as optimally as possible, i.e. that the three expressions (i), ((i+1)+(n1*n2)) and (i+(n1*n2)+(n2*n1)) are optimized. Would that be a correct description of the situation (I'm assuming it's more complicated of course)? Ciao, Michael.

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

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