This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Split simplify_unary_operation and simplify_binary_operation
- From: Roger Sayle <roger at eyesopen dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>, <gcc-patches at gcc dot gnu dot org>, Kazu Hirata <kazu at cs dot umass dot edu>
- Date: Mon, 14 Feb 2005 19:38:00 -0700 (MST)
- Subject: Re: [PATCH] Split simplify_unary_operation and simplify_binary_operation
On Mon, 14 Feb 2005, Paolo Bonzini wrote:
> > The function simplify_const_relational_operation
> > ends up being useful in its own right, and can potentially be used
> > by other RTL optimizers when its known both operands are constant.
> > Sound reasonable?
> Here is a patch, bootstrapped powerpc-apple-darwin7.7.0, regtested with
> no regressions. Ok for mainline?
I was wondering whether you (or other maintainers) could comment on
the policies for mainline patches that perform large text rearrangements
but with no functional changes, such as Paolo's patch to split the
large functions simplify_binary_operation and simplify_unary_operation
and potentially Kazu's patches for splitting fold.
These types of clean-up have both pros and cons with regards to approving
during stage3. The obvious cons are the the clean-ups aren't the same
as bug-fixes and the more intrusive they are, the less suitable they
tend to be during stage3 or on a release branch. On the other hand, if
done carefully such code rearrangements are predominantly whitespace
and pose no stability problems if thoroghly/correctly tested. But more
importantly, having these rearrangements synchronized between mainline
and a branch much simplifies the task of backporting changes and fixes
Given the above aspects/issues, I'm unsure as to what the correct
approach is. When in doubt, ask a higher authority :) Perhaps every
case is different and needs to be assessed on its own merits.
Many thanks in advance,