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: [PATCH] MIPS: Fix generation of DIV.G and MOD.G for Loongson targets.


Maciej Rozycki <Maciej.Rozycki@imgtec.com> writes:
> On Thu, 12 Jan 2017, Toma Tabacu wrote:
> 
> > > > Unfortunately, this interferes with the generation of DIV.G and
> > > > MOD.G (the <u>div<mode>3 and <u>mod<mode>3 patterns) for Loongson
> > > > targets,
> > > which
> > > > causes test failures.
> > >
> > >  What test failures?  Details please.
> > >
> >
> > It's
> > gcc.target/mips/loongson-muldiv-1.c
> > gcc.target/mips/loongson-muldiv-2.c
> > gcc.target/mips/loongson3a-muldiv-1.c
> > gcc.target/mips/loongson3a-muldiv-2.c
> > on O2, O3, and Os.
> >
> > They are also checking for the Loongson-specific multiply instruction,
> > but there are no failures for that.
> 
>  So these tests have e.g.:
> 
> NOMIPS16 st sdiv (st x, st y) { return x / y + x % y; }
> 
> and as such it looks to me like this code does legitimately use a single
> DIV instruction rather than a DIV.G and MOD.G pair, at least at -O2/-O3,
> as I'd expect two divisions to take twice as much computing time as one
> does, and the avoidance of the extra accumulator access overhead needed
> with DIV does not compensate for it.  For -Os actual code generated will
> have to be checked; I suspect DIV.G/MOD.G ought to be used rather than
> DIV/MFLO/MFHI as it's two instructions vs three.
> 
>  So as a first step I'd split these tests into individual cases covering
> signed/unsigned function pairs each of which doing a single operation
> only, i.e. smul/umul, sdiv/udiv, smod/umod, which will then be expected
> to always use the extra Loongson instructions.  This ought to provide
> the coverage originally intended (study the discussion around the
> submission of the patch that introduced these tests to double-check).

This sounds like a reasonable fix. The theme of Toma's changes has been to
improve testsuite stability rather than code gen so breaking these tests
up to cover the original goal looks OK.

>  As a further step a test case for sdivmod/udivmod will then be needed,
> to cover the use of DIV vs DIV.G/MOD.G as required for speed vs space
> optimisation.

I see no need to improve code quality currently as it would be new work.
Based on the description I expect -Os will be using DIV and MFLO/MFHI.
Adding a test to record that certain optimisation levels happen to now
get the base arch DIV instruction used could be risky for stability but
I have no objection unless the new test somehow fails when pitted against
the plethora of configurations we have to test.

>  Likewise for GSMULT/GSDIV/GSMOD, etc. (hmm, why are the signed
> MULT.G/GSMULT instruction variants never used?).

Somewhat weird but so is the presence of signed and unsigned mul in R6.
I believe that microarchitecture optimisation is possible where results
could be memoised waiting for the high part multiply to be issued and
then reused.

Since there shouldn't be any compiler change needed to resolve this then
I see no need to test specifically against loongson. Just verify the
code generated looks reasonable as per the original tests.

Thanks,
Matthew


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