This is the mail archive of the 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]

Re: [PATCH] Optimize manual byte swap implementations v3

On Sun, Feb 15, 2009 at 9:41 PM, Mark Mitchell <> wrote:
> Andrew Haley wrote:
>>> Without speaking to that particular optimization (which I don't know
>>> much about), that kind of thing isn't really a counter-argument. ?The
>>> same can happen to any optional feature of the compiler. ?It's up to the
>>> people who care about it to maintain it. ?Maybe in this particular case,
>>> it should have been on by default, but that doesn't mean that all
>>> optimizations should be.
>> Can't we just turn on this byte swap optimization throughout the gcc test
>> suites? ?I can't think of any overpowering reason not to. ?Would this
>> be enough coverage?
> I think that's orthogonal to Richard's question of whether there should
> be any optimizations at that are not enabled by default at some
> optimization level.
> But, yes, we could arrange the testsuite to run with this option, or
> that some tests run with this option, or have some people who run the
> testsuite with this option, or something. ?If we decide to include the
> byteswap pass, but disable it by default, one of those options may well
> be a good idea.
> However, my ideal outcome would be to demonstrate the benefits of the
> optimization and/or reduce the cost of the optimization so that it could
> easily be justified as on by default. ?I have every confidence that some
> programs will benefit from this optimization, and that very few will
> lose, so I think the challenge is to get the cost down.

Ok, so we're in stage1 now but still "stuck" with this, correct?  The obvious
thing would be to combine it with cse_sincos, that would save one
redundant intstruction walk (not that I think this is the costly part here).

Another possibility is to bail out early from the recursions if
BSWAP_COMPARE_SYM_NUMBER cannot be possibly the result anymore,
and/or to cache the symbolic representation for each target SSA_NAME
to avoid repeatedly computing stuff for multiple uses.  Or restrict the
walking to single-use definitions.  (maybe you can add little statistics code
and count how many time you visit an SSA_NAME for building cc1files)

The framework could also be extended to handle PR27663 I believe.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]