This is the mail archive of the
mailing list for the GCC project.
Re: Question about how to fix PR69052
- From: "Bin.Cheng" <amker dot cheng at gmail dot com>
- To: Bernd Schmidt <bernds_cb1 at t-online dot de>
- Cc: Jeff Law <law at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 26 Jan 2016 13:51:52 +0000
- Subject: Re: Question about how to fix PR69052
- Authentication-results: sourceware.org; auth=none
- References: <CAHFci280ObgaSxzCBiKKBfKONeYsXOue8i84hH=pDwynhC4PNQ at mail dot gmail dot com> <56A67CD9 dot 70405 at redhat dot com> <56A68017 dot 9020304 at t-online dot de> <CAHFci2_dvYHfSHiXKHc99wVxDJmzGJi8Gcv-rWNV=0i6FRVkKQ at mail dot gmail dot com> <56A76CED dot 3020501 at t-online dot de>
On Tue, Jan 26, 2016 at 12:56 PM, Bernd Schmidt <email@example.com> 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.