This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Help with detection of an invariant

On Mon, Dec 7, 2015 at 6:44 AM, Dominik Vogt <> 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?

  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.


> Ciao
> Dominik ^_^  ^_^
> --
> Dominik Vogt
> IBM Germany

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]