This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/23726] Missed optimizations for divmod
- From: "bjoern dot m dot haase at web dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 6 Sep 2005 13:00:05 -0000
- Subject: [Bug rtl-optimization/23726] Missed optimizations for divmod
- References: <20050904220013.23726.bjoern.m.haase@web.de>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From bjoern dot m dot haase at web dot de 2005-09-06 12:59 -------
I have done some code reading now and come to the following conclusion:
When having an expanded sequence that provides one single result, libcall
blocks are an appropriate method for making sure that a single-set insn that
carries a REG_EQUAL note is *not* deleted too early.
Libcall notes, however, do not provide a method so far for dealing with library
calls or expanded sequences that yield *two* results. E.g. they are no solution
for both, divmod4 on the one hand and arithmetic expanders doing subreg
lowering and also yielding a CC on the other hand.
In order to keep changes as small as possible, my suggestion is to change
static void
rest_of_handle_jump2 (void)
such that it no longer calls "delete_trivially_dead_insns ()" at it's very
beginning. (I'd have posted a patch, if savannah.gnu.org is down right now.)
IIUC that the trivially dead insn are in first line a performance issue because
they need memory and handling that would otherwise not be necessary, my
suggested change would not be too serious. "delete_trivially_dead_insns ()"
would be among the first things that is called in the pass that immediately
follows jump2: The first cse pass.
I'd appreciate comments on whether such trivially dead insn could prevent jump2
from realizing important optimization steps.
Bjoern.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23726