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,
Andrew
>
> Ciao
>
> Dominik ^_^ ^_^
>
> --
>
> Dominik Vogt
> IBM Germany
>
