On 07/11/2018 23:02, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Nov 05, 2018 at 06:16:16PM +0000, Renlin Li wrote:
>> Sorry, this is not correct. Instructions scheduled between x and x+1
>> directly use hard register r1.
>> It is not IRA/LRA assigning r1 to the operands.
>>
>>
>> To reproduce this particular case, you could use:
>> cc1 -O3 -marm -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp
>> gcc.c-torture/execute/builtins/memcpy-chk.c
>>
>> This insn is been splitted.
>>
>> (insn 152 150 154 11 (set (mem/c:QI (plus:SI (reg/f:SI 266)
>> (const_int 24 [0x18])) [0 MEM[(void *)&p + 20B]+4 S1 A32])
>> (reg:QI 1 r1)) "memcpy-chk-reduce.c":48:3 189 {*arm_movqi_insn}
>> (expr_list:REG_DEAD (reg:QI 1 r1)
>> (nil)))
>
> Okay, I see what is going on. The arm port often expands movmem to use
> hard registers (so that it can use load/store multiple?). This does not
> work well with scheduling and RA, and this combine feature makes it worse.
>
Yes, GCC doesn't have any way of describing the constraint "I need <n>
registers in ascending order of register number". So the only way
around this is to nail down which registers are used. In practice this
has worked pretty well for the last 20 years or so.
R.
> I don't know what to do about it in combine.
>
>
> Segher
>
