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 reload. Ideally we want alternative 2, for which gcc simply reload the mem address into a address register. r157:DI=r116:DI+r69:DI-0x10 [r157:DI]=r134:V16QI#0 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. r157:V4SI=r134:V16QI#0 [r116:DI+r69:DI-0x10]=r157:V4SI 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.
Bernd
