Wouldn't the blockage insn prevent the compiler from re-arranging
other following instructions ?
In fact, the two emit_insn() need to be seen as one instruction with
the compiler free to re-arrange other instructions around it.
This is needed to implement "mulsidi3" where the hardware use a second
instruction to return the high-part of a multiplication result, and
that second instruction needs to be issued immediately after the first
instruction which return the low-part of the multiplication. Currently
this is what is used:
(define_expand "mulsidi3"
[(set (match_operand:DI 0 "register_operand" "=r")
(mult:DI
(sign_extend:DI (match_operand:SI 1 "register_operand" "0"))
(sign_extend:DI (match_operand:SI 2 "register_operand" "r"))))]
""
{
rtx lo = gen_reg_rtx (SImode);
rtx hi = gen_reg_rtx (SImode);
emit_insn (gen_mulsi3 (lo, operands[1], operands[2]));
emit_insn (gen_mulsi3_highpart (hi, operands[1], operands[2]));
emit_move_insn (gen_lowpart (SImode, operands[0]), lo);
emit_move_insn (gen_highpart (SImode, operands[0]), hi);
DONE;
})
What is needed is for the two emit_insn() to be seen as one
instruction with the compiler free to re-arrange other instructions
around it.
Is there a better way than the blockage insn to achieve the above ?
On Thu, Apr 11, 2019 at 2:08 PM Jeff Law <law@xxxxxxxxxx> wrote:
>
> On 4/11/19 10:56 AM, William Tambe wrote:
> > How to enforce that GCC will not re-arrange two emit_insn() such that,
> > in the example below, insn2 will always follow insn1; ie:
> >
> > emit_insn (gen_insn1 ()); // emit insn1.
> > emit_insn (gen_insn2 ()); // emit insn2
> >
> There's a variety of ways to do it. A blockage insn for example. But
> I'd actually take a step back and ask why you want to do this.
>
> Jeff
