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