This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: AIX regression due to DFA scheduler merge


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]