On Mon, Dec 07, 2015 at 11:48:10AM -0800, Andrew Pinski wrote:
> On Mon, Dec 7, 2015 at 6:44 AM, Dominik Vogt <v...@linux.vnet.ibm.com> wrote:
> > On S/390 the test case gcc.dg/loop-9.c currently fails:
> >
> > void f (double *a)
> > {
> > int i;
> > for (i = 0; i < 100; i++)
> > a[i] = 18.4242;
> > }
> >
> > It seems to expect that moving 18.4242 to a register is moved out
> > of the loop, but on S/390 it isn't. It turns out that
> > move_invariant_reg() is never called from move_invariants()
> > because the invariants vector is empty. Now,
> > find_invariant_insn() checks the insn for invariants using
> > check_dependencies().
> >
> > (insn 29 28 30 3 (set (mem:DF (reg:DI 81 [ ivtmp.8 ]) [0 MEM[base: _15,
> > offset: 0B]+0 S8 A64])
> > (const_double:DF
> > 1.84241999999999990222931955941021442413330078125e+1
> > [0x0.9364c2f837b4ap+5])) .../loop-9.c:9 918 {*movdf_64}
> > (nil))
> >
> > check_dependencies() comes across reg 81 first, decides that is
> > not an invariant and returns false so that find_invariant_insn()
> > never even looks at the constant.
> >
> > Actually, the constant should be moved (from the literal pool) to
> > a floating point register (and actually is in the assembly
> > output), and that move could be moved out of the loop (it's not).
> > Where should I look for the root cause?
>
>
> Hmm,
> I want to say the predicates on movdf_64 are too lose allowing the
> above when it should not. That is movdf_64 should have pushed the
> load of the fp constant into its psedu-register and used that to do
> the storing.
Thanks! It turns out that for historical S/390[x] moves such
constants to the literal pool only after the loop-invariants pass.
That is because on old cpus it was more efficient to do a direct
memory to memory move with the MVC instruction (i.e. moving the
constant to a register warly is harmful on old cpus).
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
