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 14:43:24 +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> <CAHFci28FuXxGzJpMPPT1ZDwBT_h5MptUy=KWVKcO=He6=zYsdw at mail dot gmail dot com>
On Tue, Jan 26, 2016 at 1:51 PM, Bin.Cheng <firstname.lastname@example.org> wrote:
> 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
For the record. The only new failure is loop-9.c. Given insn
patterns as below:
insn 23 is merged into insn 24 by combine if it's run before
loop_invariant, resulting in below insn:
But we can't support the floating constant, so insn24 will be split
anyway by reload:
This time both instructions are in loop, causing a regression.
Combine may need some change if we run it before loop_invariant.
> 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.