[Top] [All Lists]

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

To: James Hogan <>
Subject: Re: [PATCH] MIPS: Implement __multi3 for GCC7 MIPS64r6 builds
From: "Maciej W. Rozycki" <>
Date: Fri, 8 Dec 2017 23:52:05 +0000
Cc: Ralf Baechle <>, Thomas Petazzoni <>, Matthew Fortune <>, Florian Fainelli <>, "Waldemar Brodkorb" <>, <>
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
Original-recipient: rfc822;
References: <20171206085034.3869dc9d@windsurf.lan> <>
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
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?

> 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.


<Prev in Thread] Current Thread [Next in Thread>