This is the mail archive of the
mailing list for the GCC project.
Re: Combine four insns
- From: Steven Bosscher <stevenb dot gcc at gmail dot com>
- To: Bernd Schmidt <bernds at codesourcery dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 6 Aug 2010 17:07:47 +0200
- Subject: Re: Combine four insns
- References: <4C5C20D0.firstname.lastname@example.org>
On Fri, Aug 6, 2010 at 4:48 PM, Bernd Schmidt <email@example.com> wrote:
> I'd argue that compile-time shouldn't be our top priority, as it's one
> of the few things that still benefits from Moore's Law, while the same
> may not be true for the programs we compile. ?I expect people will argue
> a 1% slowdown is unacceptable, but in that case I think we need to
> discuss whether users are complaining about slow compiles more often
> than they complain about missed optimizations - in my experience the
> reverse is true.
It depends where you look. In the free software community, the
majority of complaints is about compile time, but perhaps for your
customers the missed optimizations are more important.
But perhaps the optimization can be performed in another place than
combine? If it's just a relatively small set of common patterns, a
quick GIMPLE pass may be preferable.
(I know, it's the old argument we've had before: You have a real fix
now for a real problem, others (incl. me) believe that to fix this
problem in combine is a step away from sane instruction selection that
GCC may not have for years to come...)
What does the code look like, that is optimized so much better with 4
insns to combine? It looks like code that could come from bitfield
manipulations, which is an area where it's well-known that GCC does
not always optimize too well.