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:
signature.asc
Description: Digital signature
