Question regarding preventing optimizing out of register in expansion

Jeff Law law@redhat.com
Wed Jun 27 10:26:00 GMT 2018


On 06/26/2018 01:20 PM, Peryt, Sebastian wrote:
>> Subject: Re: Question regarding preventing optimizing out of register in
>> expansion
>>
>> On 6/26/18 4:05 AM, Peryt, Sebastian wrote:
>>> With some changes simplified implementation of my expansion is as follows:
>>> tmp_op0 = gen_reg_rtx (mode);
>>> emit_move_insn (tmp_op0, op0);
>>
>> You set tmp_op0 here, and then....
>>
>>
>>> emit_insn (gen_rtx_SET (tmp_op0, reg));
>>
>> You set it again here without ever using it above, so it's dead code, which
>> explains why it's removed.
> 
> Oh.... My bad - I oversimplified my code. Now I can see it.
> 
> This should be more appropriate:
> tmp_op0 = gen_reg_rtx (mode);
> emit_move_insn (tmp_op0, op0);
> tmp_op1 = gen_reg_rtx (mode);
> emit_move_insn (tmp_op1, op1);
> 
> // This is important part
> reg = gen_rtx_REG(wide_mode, XMM2_REG);
> op3 = gen_rtx_PLUS (mode, tmp_op1, GEN_INT (128));
> emit_insn (gen_rtx_SET (reg, op3));
> 
> emit_insn (gen_myinsn(op2, reg));
> 
> op3 = gen_rtx_PLUS (mode, tmp_op0, GEN_INT (128));
> emit_insn (gen_rtx_SET (op3, reg));
> ////
> 
> Also I'd like to one more time point out that without additional -mavx or -mavx2 
> I'm getting expected register moves before and after my instr. With those options
> only *after*. This is the part that I don't get especially - why.
I don't know the details of what you're doing, but the expansion phase
may be trying make operands you provide fit the predicate for expanders
or named patterns you're using.  It may also be the case that copies are
created as a result of other define_expands, etc.

The way to figure this out is to note the insn # for the unexpected
copy.  Then put a breakpoint in emit_insn that is conditional on
cur_insn_uid having that value.  You can then walk up the callchain and
try to ascertain why those copies were made.

jeff



More information about the Gcc mailing list