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

[Maciej W. Rozycki]

On Mon, 9 Jan 2017, Toma Tabacu wrote:

> The expand_DIVMOD function, introduced in r241660, will pick the divmod<mode>4
> (or the udivmod<mode>4) pattern when it checks for the presence of hardware
> div/mod instructions, which results in the generation of the old DIV
> instruction.
> 
> 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.

> This patch prevents the selection of divmod<mode>4 and udivmod<mode>4 when
> targeting Loongson by adding !ISA_HAS_DIV3 to the match condition.
> ISA_HAS_DIV3 checks for the presence of the 3-operand Loongson-specific DIV.G
> and MOD.G instructions.
> 
> Tested with mips-mti-elf.

 And Loongson hardware presumably, right?

> 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