[Bug rtl-optimization/47477] [4.6 regression] Sub-optimal mov at end of method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.6.0 |4.7.0
[Bug rtl-optimization/47477] [4.6 regression] Sub-optimal mov at end of method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/47477] [4.6 regression] Sub-optimal mov at end of method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-08 14:39:25 UTC --- (In reply to comment #7) forwprop is a forward walk, for this kind of optimization we want to walk backwards, from the narrowing integer conversion to the operations and whenever we change some operation see if we can change the def_stmts of its operands too. forwprop does both, walking forward and backward today. It's just misnamed now ;)
[Bug rtl-optimization/47477] [4.6 regression] Sub-optimal mov at end of method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-29 19:40:25 UTC --- forwprop is a forward walk, for this kind of optimization we want to walk backwards, from the narrowing integer conversion to the operations and whenever we change some operation see if we can change the def_stmts of its operands too.
[Bug rtl-optimization/47477] [4.6 regression] Sub-optimal mov at end of method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477
--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-28
11:04:19 UTC ---
(In reply to comment #4)
Alternatively, this narrowing of word mode operations could as well be done
during tree optimizations. I think the FE is the only place which performs
them,
as can be seen if you modify your testcase to do:
void *
add (void *a, void *b)
{
return (void *)(__INTPTR_TYPE__) ((long long)(__INTPTR_TYPE__) a + ((long
long)(__INTPTR_TYPE__) b ~1L));
}
instead of
void *
add (void *a, void *b)
{
long long tmp = (long long)(__INTPTR_TYPE__) a + ((long
long)(__INTPTR_TYPE__) b ~1L);
return (void *)(__INTPTR_TYPE__) tmp;
}
But unfortunately we have nothing which performs this later on (gimple-fold?).
As it needs to combine several statements tree forwprop is our current
place to deal with this (as our tree combiner). Similar to the
new associate_plusminus code we should have combiners (not re-using fold)
to combine conversions.
[Bug rtl-optimization/47477] [4.6 regression] Sub-optimal mov at end of method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target|i686|i?86-*-* --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-27 11:22:39 UTC --- The specific pattern looks easy to catch in a peephole2 or machine dependent reorg (for destructive arith archs).
[Bug rtl-optimization/47477] [4.6 regression] Sub-optimal mov at end of method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-27
17:21:04 UTC ---
Not so easily, addsi3_cc is quite specialized pattern and if we add peepholes
to help with reg1 = reg1 op reg2; reg2 = reg1 [reg1 DEAD];
I think we'd add it only for a couple of most common arithmetics ops.
Wonder whether the splitters couldn't be smarter here, when splitting a
doubleword addition see that we only care about a SImode subreg thereof.
Or, if lower-subreg.c could do something about it, optimize
(insn 10 9 11 2 (parallel [
(set (reg:DI 74)
(plus:DI (reg:DI 71)
(reg:DI 73)))
(clobber (reg:CC 17 flags))
]) pr47477.c:4 243 {*adddi3_doubleword}
(nil))
(insn 11 10 12 2 (set (reg:SI 70)
(subreg:SI (reg:DI 74) 0)) pr47477.c:5 64 {*movsi_internal}
(nil))
into just SImode addition.
[Bug rtl-optimization/47477] [4.6 regression] Sub-optimal mov at end of method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||rth at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-27
17:45:33 UTC ---
Alternatively, this narrowing of word mode operations could as well be done
during tree optimizations. I think the FE is the only place which performs
them,
as can be seen if you modify your testcase to do:
void *
add (void *a, void *b)
{
return (void *)(__INTPTR_TYPE__) ((long long)(__INTPTR_TYPE__) a + ((long
long)(__INTPTR_TYPE__) b ~1L));
}
instead of
void *
add (void *a, void *b)
{
long long tmp = (long long)(__INTPTR_TYPE__) a + ((long
long)(__INTPTR_TYPE__) b ~1L);
return (void *)(__INTPTR_TYPE__) tmp;
}
But unfortunately we have nothing which performs this later on (gimple-fold?).
[Bug rtl-optimization/47477] [4.6 regression] Sub-optimal mov at end of method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477 --- Comment #5 from Tony Poppleton tony.poppleton at gmail dot com 2011-01-27 17:58:12 UTC --- The modified testcase in comment #4 also fixes the original bug with redundent push/pop of BX (as described in PR35926), so fixing this during tree optimizations would be good.
[Bug rtl-optimization/47477] [4.6 regression] Sub-optimal mov at end of method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Target||i686 Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.27 05:41:05 CC||bernds at gcc dot gnu.org, ||hjl.tools at gmail dot com Host|Linux x86-64| Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-01-27 05:41:05 UTC --- It is caused by revision 162418: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00772.html
