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: [lra] Cleanup the use of offmemok and don't count spilling cost for it

On 07/04/2016 04:05 PM, Jiong Wang wrote:
And the corresponding s390 patten is "mov<mode>" for V_128.

(define_insn "mov<mode>"
  [(set (match_operand:V_128 0 "" "=v,v,R,  v,  v,  v,  v,  v,v,d")
          (match_operand:V_128 1 "" "v,R,v,j00,jm1,jyy,jxx,jKK,d,v"))]

As the offset "-16" does not qualify s390_short_displacement, we need a

Ideally we want alternative 2, for which gcc simply reload the mem
address into a address register.


While after r237277, gcc is treating the reload of insn 41 as a spill
and thus increased the costs for it, then alternative 8 beat alternative
2, thus the following reload sequences are generated.


GCC move the vector register into general register, then a second
instruction to store the general register into memory so it can match
alternative 8, which is "v", "d".

However the second instructions still constains the illegal mem address,
thus a further reload triggered, and gcc triggers above max number
reload issue.

The functional chang of this patch is to make gcc don't treat an memory
address reload as spill which is regression caused by r237277.

Does this explanation make sense?

Yes, it explains well what's going on. I think the part of your patch that avoids counting a reload of an address as a spill looks ok. I'm uncertain whether the code still has issues after that, it seems a little iffy not to count the cost of reloading the memory address at all. We might have to add code at some point to detect if we're reloading a move instruction and would be generating an identical one when picking a given alternative.


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