------- Comment #4 from rakdver at kam dot mff dot cuni dot cz 2007-09-16 22:07 ------- Subject: Re: [4.3 Regression] gfortran.dg/g77/19990826-3.f fails at -O1
> What happens in this testcase is (mis)behaviour of invariant code motion. > On instruction: > (set (mem/c/i:SI (plus:DI (reg/f:DI 113 sfp) > (const_int 80 [0x50])) [3 S4 A32]) > (fix:SI (reg:DF 135))) > > the invariant code is trying to replace the write->load pair, however the > truncsfdf2 expander is expanding fix from reg to reg will offload the value to > memory again, so we are replacing load by: > > (insn 44 0 45 (parallel [ > (set (mem/c/i:SI (plus:DI (reg/f:DI 113 sfp) > (const_int 84 [0x54])) [3 S4 A32]) > (fix:SI (reg:DF 135))) > (clobber (reg:DI 138)) > ]) -1 (nil)) > > (insn 45 44 46 (set (reg:SI 137) > (mem/c/i:SI (plus:DI (reg/f:DI 113 sfp) > (const_int 84 [0x54])) [3 S4 A32])) -1 (expr_list:REG_EQUAL > (fix:SI (reg:DF 135)) > (nil))) > > (insn 46 45 0 (set (reg:SI 136) > (reg:SI 137)) -1 (nil)) > > This is not very sane transformation at all IMO. Actually, it may make some sense -- the newly generated memory store & load are outside of the loop; so the code inside the loop is simplified, and in some cases we might even avoid memory accesses inside the loop. Nevertheless, force_operand in move_invariant_reg causes other problems as well, so I guess I will remove this code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33348
