Re: [PATCH] MIPS: Implement __multi3 for GCC7 MIPS64r6 builds

[James Hogan <james.hogan@mips.com>]

[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]

On Fri, Dec 08, 2017 at 11:52:05PM +0000, Maciej W. Rozycki wrote:
> On Wed, 6 Dec 2017, James Hogan wrote:
> 
> > GCC7 is a bit too eager to generate suboptimal __multi3 calls (128bit
> > multiply with 128bit result) for MIPS64r6 builds, even in code which
> > doesn't explicitly use 128bit types, such as the following:
> > 
> > unsigned long func(unsigned long a, unsigned long b)
> > {
> > 	return a > (~0UL) / b;
> > }
> > 
> > Which GCC rearanges to:
> > 
> > return (unsigned __int128)a * (unsigned __int128)b > 0xffffffff;
> 
>  You mean:
> 
> return (unsigned __int128)a * (unsigned __int128)b > 0xffffffffffffffff;
> 
> presumably, or is there another bug here?

Yes, thats what was meant. It was copy + pasted from Ralf's analysis.

Thanks
James

> 
> > Therefore implement __multi3, but only for MIPS64r6 with GCC7 as under
> > normal circumstances we wouldn't expect any calls to __multi3 to be
> > generated from kernel code.
> 
>  That does look bad; I'd expect a `umulditi3' (widening 64-bit by 64-bit 
> unsigned multiplication) kind of operation instead, which should expand 
> internally.  And we only really need to execute DMUHU and then check the 
> result for non-zero here, because the value of the low 64 bits of the 
> product does not matter for the evaluation of the expression.
> 
>  I don't know offhand if such a transformation can be handled by GCC as it 
> stands by tweaking the MIPS backend without a corresponding update to the 
> middle end though.
> 
>   Maciej
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]