AIX regression due to DFA scheduler merge
Vladimir Makarov
vmakarov@redhat.com
Fri May 31 11:11:00 GMT 2002
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
117) ...
(set (subreg:SI ((reg:DI 122) 4) ... (expr_list:REG_NO_CONFLICT (reg:DI
117) ...
...
(set (subreg:SI ((reg:DI 123) 0) ... (expr_list:REG_NO_CONFLICT (reg:DI
117) ...
(set (subreg:SI ((reg:DI 123) 4) ... (expr_list:REG_NO_CONFLICT (reg:DI
117) ...
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
group.
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
optimization.
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.
Vlad
More information about the Gcc-patches
mailing list