This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Fix for PR26222
Hello,
> >it is possible that is not the proper fix for the PR, but I have no
> >idea how to solve the problem differently. Consider the following
> >insn:
> >
> >(insn 94 93 95 12 (parallel [
> > (set (mem/c/i:SI (plus:SI (reg/f:SI 113 sfp)
> > (const_int 64 [0x40])) [9 S4 A32])
> > (fix:SI (reg:DF 127 [ pretmp.31 ])))
> > (clobber (reg:DI 165))
> > ]) -1 (nil)
> > (nil))
> >
> >where reg 127 is loop invariant. loop-invariant.c tries to move
> >the (fix:SI (reg:DF 127 [ pretmp.31 ])) out of the loop. However,
> >gen_move_insn produces the following insn:
> >
> >(insn 208 164 52 5 (set (reg:SI 194)
> > (fix:SI (reg:DF 127 [ pretmp.31 ]))) -1 (nil)
> > (nil))
> >
> >that is not valid on ppc64-linux.
>
> For some reason this is making me worried. If I read your description
> correctly, we add another temporary stack slot and use that. Wouldn't
> this also slow down the fact now we have two stores/loads and still have
> one inside the loop or does a future RTL pass is able to remove the
> loading and storing in the temporary inside the loop?
the part of the code in loop (insn 94) is replaced with
(set (mem/c/i:SI (plus:SI (reg/f:SI 113 sfp)
(const_int 64 [0x40])) [9 S4 A32])
(reg:SI 194))
Which indeed does not help too much. Nevertheless, there is no easy way
how to detect this case, and I do not intend to add any pass that would
further optimize this. Invariant motion for this construction should
happen on tree level (which seems to happen for the C testcase, but
probably because of exceptions not for the Java one).
Zdenek