Le 29/01/2020 à 08:14, Thomas Gleixner a écrit :
Andy Lutomirski writes:
On Thu, Jan 16, 2020 at 11:57 AM Thomas Gleixner wrote:
Andy Lutomirski writes:
On Thu, Jan 16, 2020 at 9:58 AM Christophe Leroy
Would mul_u64_u64_shr() be a good alternative? Could we adjust it to
assume the
Andy Lutomirski writes:
> On Thu, Jan 16, 2020 at 11:57 AM Thomas Gleixner wrote:
>>
>> Andy Lutomirski writes:
>> > On Thu, Jan 16, 2020 at 9:58 AM Christophe Leroy
>> >
>> > Would mul_u64_u64_shr() be a good alternative? Could we adjust it to
>> > assume the shift is less than 32? That
On Thu, Jan 16, 2020 at 11:57 AM Thomas Gleixner wrote:
>
> Andy Lutomirski writes:
> > On Thu, Jan 16, 2020 at 9:58 AM Christophe Leroy
> >
> > Would mul_u64_u64_shr() be a good alternative? Could we adjust it to
> > assume the shift is less than 32? That function exists to benefit
> > 32-bit
Andy Lutomirski writes:
> On Thu, Jan 16, 2020 at 9:58 AM Christophe Leroy
>
> Would mul_u64_u64_shr() be a good alternative? Could we adjust it to
> assume the shift is less than 32? That function exists to benefit
> 32-bit arches.
We'd want mul_u64_u32_shr() for this. The rules for mult and
On Thu, Jan 16, 2020 at 9:58 AM Christophe Leroy
wrote:
>
> On powerpc/32, GCC (8.1) generates pretty bad code for the
> ns >>= vd->shift operation taking into account that the
> shift is always < 32 and the upper part of the result is
> likely to be nul. GCC makes reversed assumptions
On powerpc/32, GCC (8.1) generates pretty bad code for the
ns >>= vd->shift operation taking into account that the
shift is always < 32 and the upper part of the result is
likely to be nul. GCC makes reversed assumptions considering
the shift to be likely >= 32 and the upper part to be like not
