Hi,

> > Bernd, do you think that this check would be sufficient and safe?
> > I'm not sure what would be better: check the mode, nregs plus perhaps
> > consider tying only if nregs == 1.
>
> Hmm, but shouldn't the regno still be the same? Or is this a case where
> we have a multi-word chain like ax/dx and then something like a "set bx,
> dx" involving only a part of it, but the entire chain dies?

The more I stare at this the more confusing it is. Yes, it appears to be a 
multi-word
chain and when a subset dies then the whole chain dies.

Let's consider the following snippet:
...
(insn 1467 1465 1466 68 (set (reg:DI 4 r4 [626])
        (mult:DI (zero_extend:DI (reg:SI 1 r1 [orig:698 bbase_yn ] [698]))
            (zero_extend:DI (reg:SI 12 ip [orig:700 _302 ] [700])))) 
/scratch2/check-other-ports/src/gcc/libgfortran/generated/matmul_i8.c:284 54 
{*umulsidi3_v6}
     (nil))
(insn 1466 1467 4288 68 (set (reg:SI 2 r2 [625])
        (plus:SI (mult:SI (reg:SI 12 ip [orig:700 _302 ] [700])
                (reg:SI 0 r0 [orig:699 bbase_yn+4 ] [699]))
            (reg:SI 2 r2 [624]))) 
/scratch2/check-other-ports/src/gcc/libgfortran/generated/matmul_i8.c:284 43 
{*mulsi3addsi_v6}
     (expr_list:REG_DEAD (reg:SI 12 ip [orig:700 _302 ] [700])
        (nil)))
(insn 4288 1466 1469 68 (set (reg:SI 12 ip [1933])
        (reg:SI 5 r5 [+4 ])) 
/scratch2/check-other-ports/src/gcc/libgfortran/generated/matmul_i8.c:284 174 
{*arm_movsi_insn}
     (expr_list:REG_DEAD (reg:SI 5 r5 [+4 ])
        (nil)))
...

When the input operand in insn 4288 is terminated as dead then the
terminated_this_insn->regno points to register 4 but this_regno is 5.
terminated_this_insn->last->insn points to insn 1467.
I presume "[+4 ]" for register 5 in the dump indicates that this is a part of
the multi-word register.

When a new chain is created for the output operand with register 12
and tying is attempted then we get an assertion error.

> I guess this is ok to stop the failures for now, but you may want to
> move the check to the point where we set terminated_this_insn. Also, as
> I pointed out earlier, clearing terminated_this_insn should probably
> happen earlier.
>
> Bernd

Ah yes, I forgot to move this. I'll move it and commit the patch in the morning.

Regards,
Robert

Reply via email to