On Mon, Sep 29, 2008 at 5:08 PM, Erik Corry <[EMAIL PROTECTED]> wrote: > The mtune is gone right now as is march. The O9 goes away in my next > change (in review).
To clarify the O9 is changed to an O3. It appears that we should have O3 for the parser and perhaps the regexp. For the rest O2 is probably better due to code size considerations. We may want to experiment with -Os or -O2 + selected optimizations from O3 that we have good experience with. > > On Mon, Sep 29, 2008 at 10:18 AM, Dean McNamee <[EMAIL PROTECTED]> wrote: >> If we're deciding to keep this change, it won't be acceptable for the >> linux/mac Chromium builds. Is there a way we can control it at least? >> The code size increase of -O3 (-O9 in this change) is likely not to >> be a win for us, and we definitely don't want the mtune. >> >> On Fri, Sep 26, 2008 at 6:08 PM, Erik Corry <[EMAIL PROTECTED]> wrote: >>> >>> >>> On Fri, Sep 26, 2008 at 4:56 PM, Dean McNamee <[EMAIL PROTECTED]> wrote: >>>> >>>> There is nothing beyond O3, so O9 is kinda a bad joke. Also, any >>>> guesses why GCC thinks those variables might go uninitialized? (I saw >>>> the same problem). >>>> >>>> Seconds, I do not think we should -mtune=nocona for a few reasons. >>>> nocona is a NetBurst chip, so we would be tuning towards p4. If >>>> anyone we should tune towards Core Duo, however... >>> >>> I think we should tune towards a specific chip because we want to optimize >>> for the most popular chip regardless of the hardware we happen to have >>> available to build on. But right now I am going to revert the tuning stuff >>> because it doesn't work for ARM (duh!). >>>> >>>> We should not tune towards a specific chip, either 1) mtune=generic, >>>> which will tune for a balance of all chips, or mtune=native, which >>>> will issue a cpuid, and tune for whatever machine you are building on. >>>> >>>> On Fri, Sep 26, 2008 at 2:21 PM, <[EMAIL PROTECTED]> wrote: >>>> > >>>> > Let's try it out. Please revert you changes if this does not >>>> > yield a measurable speedup. >>>> > >>>> > LGTM, >>>> > Lars >>>> > >>>> > >>>> > http://codereview.chromium.org/4298/diff/1/2 >>>> > File src/objects.cc (right): >>>> > >>>> > http://codereview.chromium.org/4298/diff/1/2#newcode1694 >>>> > Line 1694: uint32_t index = 0; >>>> > Please add a comment why this assignment is necessary. >>>> > >>>> > http://codereview.chromium.org/4298/diff/1/2#newcode1741 >>>> > Line 1741: uint32_t index = 0; >>>> > Please move the assignment into AsArrayIndex in objects-inl.h. >>> >>> Oops, missed those! >>> >>>> >>>> > >>>> > http://codereview.chromium.org/4298 >>>> > >>>> > >>>> > >>>> > >>> >>> >>> >>> -- >>> Erik Corry, Software Engineer >>> Google Denmark ApS. CVR nr. 28 86 69 84 >>> c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 Copenhagen K, >>> Denmark. >>> >> > > > > -- > Erik Corry, Software Engineer > Google Denmark ApS. CVR nr. 28 86 69 84 > c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 > Copenhagen K, Denmark. > -- Erik Corry, Software Engineer Google Denmark ApS. CVR nr. 28 86 69 84 c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 Copenhagen K, Denmark. --~--~---------~--~----~------------~-------~--~----~ v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev -~----------~----~----~----~------~----~------~--~---
