This is the mail archive of the
mailing list for the GCC project.
Re: AIX regression due to DFA scheduler merge
- From: Vladimir Makarov <vmakarov at redhat dot com>
- To: David Edelsohn <dje at watson dot ibm dot com>
- Cc: Jeffrey Law <law at redhat dot com>, gcc-patches at gcc dot gnu dot org, Mark Mitchell <mark at codesourcery dot com>
- Date: Fri, 31 May 2002 13:57:21 -0400
- Subject: Re: AIX regression due to DFA scheduler merge
- References: <200205310222.WAA23204@makai.watson.ibm.com>
David Edelsohn wrote:
> >>>>> Vladimir Makarov writes:
> Vlad> Ok, David. I'll look at this. But I can guess (knowing the sources) it
> Vlad> is not because of the merge. There were other changes besides the
> Vlad> merge.
> Some additional datapoints: -mcpu=604e fails. -mcpu=630 fails.
> -mcpu=750 works. -mcpu=7400 works. -mcpu=7450 works.
> I believe that the automatic regression tester is not failing
> because sysv4.h defines:
> #define PROCESSOR_DEFAULT PROCESSOR_PPC750
> AIX defaults to PPC604.
> I can send you the ChangeLog diff between the last working version
> and the version that began to fail. The dfa-branch merge is the only
> relevant change.
> I am not saying that the DFA changes are inherently faulty, but I
> think that the merge may have exposed a latent bug. After the merge, GCC
> schedules the instructions differently with the exact same, old
> description. We may have just been lucky with the scheduling before.
Yes, you are absolutely right. This is a latent scheduler bug. And we
wre lucky not to meet the bug. The scheduler ignores REG_NO_CONFLICT at
all. So we have two libcall sequences
(set (subreg:SI ((reg:DI 122) 0) ... (expr_list:REG_NO_CONFLICT (reg:DI
(set (subreg:SI ((reg:DI 122) 4) ... (expr_list:REG_NO_CONFLICT (reg:DI
(set (subreg:SI ((reg:DI 123) 0) ... (expr_list:REG_NO_CONFLICT (reg:DI
(set (subreg:SI ((reg:DI 123) 4) ... (expr_list:REG_NO_CONFLICT (reg:DI
Because the scheduler ignores REG_NO_CONFLICT, there are no dependencies
between insns in two groups and the scheduler intermixes them. Register
allocator takes the REG_NO_CONFLICT into account and assigns the same
register to pseudos 122 and 123.
I see the following solutions of the problem:
o as REG_NO_CONFLICT is inside libcalls we could schedule libcall as
o take REG_NO_CONFLICT into account during building dependencies.
The 1st solution is easier but it is wrong because it means a
degradation and the advantages of gcc libcalls are not used in
The 2nd solution is better although it is not so easy as the 1st one.
I'll make a patch (based on the 2nd solution) on the next week and send
it to you.