[PATCH] MIPS: Fix generation of DIV.G and MOD.G for Loongson targets.

[Toma Tabacu]

> Maciej Rozycki writes:
> 
> >
> > 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.

> 
> > This solution might be excessive, however, as it effectively forbids the
> > generation of the old DIV instruction for Loongson targets, which actually do
> > support it.
> 
>  What's the purpose of this change other than "fixing test failures"?
> Can you please demonstrate a technical justification of this change?  Has
> there been a code quality regression which this patch addresses for
> example?  What about source code which did emit `divmod<mode>4' and
> `udivmod<mode>4' patterns on Loongson targets before r241660?
> 
>  Given that the DIV.G, MOD.G and accumulator DIV instructions (and their
> unsigned counterparts) are all available the compiler should have freedom
> to choose whichever hardware operation is the most suitable for the
> calculations required according to code generation options selected and
> artificially disabling some hardware instructions does not appear to be a
> move in that direction to me.
> 
>   Maciej

I'll be honest here: I don't know when the compiler should generate the
Loongson-specific division and modulo instructions, I don't have access to
Loongson hardware, and I wasn't even specifically trying to fix Loongson-related
issues.

I admit that the patch was submitted in haste, and I now realize that my
proposal was unfounded and that I don't have the means to find a satisfactory
solution. Too much wishful thinking on my part.

However, there is a legitimate underlying issue here and I felt it had to be
brought up, but this should have been a bug report, not a patch submission.

Anyway, thank you for the feedback.

Regards,
Toma