Ping: [PATCH GCC/ARM] Fix problem that hardreg_cprop opportunities are missed on thumb1

Richard Sandiford rdsandiford@googlemail.com
Tue Sep 4 22:08:00 GMT 2012


"Bin Cheng" <bin.cheng@arm.com> writes:
>> Hi,
>> For thumb1, arm-gcc rewrites move insn into subtract of ZERO in peephole2
> pass
>> intentionally, then executes
>> pass_if_after_reload/pass_regrename/pass_cprop_hardreg sequentially.
>> 
>> In this scenario, copy propagation opportunities are missed because:
>>   1. the move insns are re-written.
>>   2. pass_cprop_hardreg currently don't notice the subtract of ZERO.
>> 
>> This patch fixes the problem and the logic is:
>>   1. notice the plus/subtract of ZERO in pass_cprop_hardreg.
>>   2. if the last insn providing information about conditional codes is in
> the
>> form of "dest_reg = src_reg - 0", record the src_reg in newly added field
>> thumb1_cc_op0_src of structure machine_function.
>>   3. in pattern "cbranchsi4_insn", check thumb1_cc_op0_src along with
>> thumb1_cc_op0 to save one comparison insn.
>> 
>> I measured the patch on CSiBE, about 600 bytes are saved for both O2 and
> Os on
>> cortex-m0 without any regression.
>> 
>> I also tested the patch on
>> arm-none-eabi+cortex-m0/arm-none-eabi+cortex-m3/i686-pc-linux and no
>> regressions introduced.
>> 
>> So is it OK?
>> 
>> Thanks
>> 
>> 2012-08-13  Bin Cheng  <bin.cheng@arm.com>
>> 
>> 	* regcprop.c (copyprop_hardreg_forward_1) Notice copies in the form
> of
>> 	subtract of ZERO.
>> 	* config/arm/arm.h (thumb1_cc_op0_src) New field.
>> 	* config/arm/arm.c (thumb1_final_prescan_insn) Record
> thumb1_cc_op0_src.
>> 	* config/arm/arm.md (cbranchsi4_insn) Check thumb1_cc_op0_src along
>> with
>> 	thumb1_cc_op0.
>
> Ping?
>
> Hi Ramana, could you help me review this patch?
> Hi Eric, Richard, could you help me review the change in regcprop.c?

Subtraction of zero isn't canonical rtl though.  Passes after peephole2
would be well within their rights to simplify the expression back to a move.
>From that point of view, making the passes recognise (plus X 0) and
(minus X 0) as special cases would be inconsistent.

Rather than make the Thumb 1 CC usage implicit in the rtl stream,
and carry the current state around in cfun->machine, it seems like it
would be better to get md_reorg to rewrite the instructions into a form
that makes the use of condition codes explicit.

md_reorg also sounds like a better place in the pipeline than peephole2
to be doing this kind of transformation, although I admit I have zero
evidence to back that up...

Richard



More information about the Gcc-patches mailing list