Richard Sandiford <richard.sandif...@linaro.org>

> The "?" change seems to make intrinsic sense given the extra cost of the
> GPR alternative.  But I think the real reason for this failure is that
> we define no V1DF patterns, and target-independent code falls back to
> using moves in the corresponding *integer* mode.  So for that function
> we generate the rather ugly code:

This:

typedef struct { double x; } X;
X f2(X *p)
{
  return *p;
}

emits at expand:

(insn 6 3 7 2 (set (reg:DF 90 [ D.21009 ])
        (mem:DF (reg/v/f:DI 92 [ p ]) [2 *p_2(D)+0 S8 A64])) 
"vect_copy_lane_1.c":26 -1
     (nil))
(insn 7 6 8 2 (set (subreg:DF (reg:DI 94) 0)
        (reg:DF 90 [ D.21009 ])) "vect_copy_lane_1.c":26 -1
     (nil))
(insn 8 7 9 2 (set (reg:DI 95)
        (reg:DI 94)) "vect_copy_lane_1.c":26 -1
     (nil))
(insn 9 8 13 2 (set (reg:DF 91 [ <retval> ])
        (subreg:DF (reg:DI 95) 0)) "vect_copy_lane_1.c":26 -1
     (nil))

So the underlying cause is the structure passing code. Things get worse when 
you return
2 doubles and it really becomes horrific at 3...

Wilco
    

Reply via email to