Re: Question about how to fix PR69052

["Bin.Cheng" <amker dot cheng at gmail dot com>]

On Tue, Jan 26, 2016 at 12:56 PM, Bernd Schmidt <bernds_cb1@t-online.de> wrote:
> On 01/26/2016 10:48 AM, Bin.Cheng wrote:
>>
>> Yes, I moved whole loop pass (also the pass_web) after combine and it
>> worked.  A combine pass before loop-invariant can fix this problem.
>> Below passes are currently between loop transform and combine:
>>
>>        NEXT_PASS (pass_web);
>>        NEXT_PASS (pass_rtl_cprop);
>>        NEXT_PASS (pass_cse2);
>>        NEXT_PASS (pass_rtl_dse1);
>>        NEXT_PASS (pass_rtl_fwprop_addr);
>>        NEXT_PASS (pass_inc_dec);
>>        NEXT_PASS (pass_initialize_regs);
>>        NEXT_PASS (pass_ud_rtl_dce);
>>
>> I think pass_web needs to be after loop transform because it's used to
>> handle unrolled register live range.
>> pass_fwprop_addr and pass_inc_dec should stay where they are now.  And
>> putting pass_inc_dec before loop unroll may be helpful to keep more
>> auto increment addressing mode chosen by IVO.
>> We should not need to duplicate pass_initialize_regs.
>> So what's about pass_rtl_cprop, cse2 and dse1.  Should these pass be
>> duplicated after loop transform thus loop transformed code can be
>> cleaned up?
>
>
> Hard to tell in advance - you might want to experiment a bit; set up a large
> collection of input files and see what various approaches do to code
> generation. In any case, I suspect this is gcc-7 material (unfortunately).

Quite surprising, there is only one new failure after moving loop
transforms (only along with pass_web).  Yes, it is GCC7 change, will
revisit this to see if it makes substantial code generation
difference.  Anyway, for the bug itself, there might be simple fix in
x86 backend according to newest update.

Thanks,
bin