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: PR63633: May middle-end come up width hard regs for insn expanders?

On Mon, Apr 20, 2015 at 10:11 PM, Vladimir Makarov wrote:
> I might be wrong but I think you have a bloated code because you use
> scratches.  I already told several times that usage of scratch is always a
> bad idea.  It was a bad idea for an old RA and is still a bad idea for IRA.
> The usage of scratches should be prohibited, probably we should write it
> somewhere.  It is better to use just a regular pseudo instead.

Thanks Vladimir, I didn't know this.
Does this mean that, for example, extendsidi in would be
better if it did not use match_scratch?

The expander and the 32-bits version of the insn currently look like this:

(define_expand "extendsidi2"
  [(set (match_operand:DI 0 "register_operand")
        (sign_extend:DI (match_operand:SI 1 "register_operand")))]
  if (!TARGET_64BIT)
      emit_insn (gen_extendsidi2_1 (operands[0], operands[1]));

(define_insn "extendsidi2_1"
  [(set (match_operand:DI 0 "nonimmediate_operand" "=*A,r,?r,?*o")
        (sign_extend:DI (match_operand:SI 1 "register_operand" "0,0,r,r")))
   (clobber (reg:CC FLAGS_REG))
   (clobber (match_scratch:SI 2 "=X,X,X,&r"))]
  "#") // there is a post reg-alloc splitter

If I understand your remark on SCRATCH correctly, then the expander
should use gen_reg_rtx for operand 2 of extendsidi2_1; and the insn
should use match_operand on operand 2 instead of match_scratch.

When is a scratch still OK?

The most common pattern in i386 is (clobber (match_scratch ...)))
which probably always results in the need for a register that IRA
doesn't see, so I assume that this is one of the cases where you would
recommend using a pseudo instead...? (A quick grep on config/*.md
shows 952 cases like this, and 113 match_scratch uses of a different

A match_scratch or (clobber (scratch)) in a define_peephole2 should
also always be fine, because that's just a way to see if there is a
suitable register available to perform the peephole code
transformation (peephole2 runs after reg-alloc).

(mem:BLK (scratch)) is always OK,

> Why it is a bad idea?  Because IRA (or the old global RA) does not take
> them into account *at all*.  It means that IRA might think that there are
> enough registers for pseudos but in reality it is wrong because of
> scratches in live range of the pseudos.

Is there a reason why IRA doesn't replace scratches with pseudos, like
LRA does (and IIRC reload does, also)?


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