Cornelia Huck <coh...@redhat.com> writes:
> On Mon, 14 Jan 2019 13:12:35 +0100
> Thomas Huth <th...@redhat.com> wrote:
>
<snip>
>>
>> diff --git a/include/fpu/softfloat-macros.h b/include/fpu/softfloat-macros.h
>> index b1d772e..bd5b641 100644
>> --- a/include/fpu/softfloat-macros.h
>> +++ b/include/fpu/softfloat-macros.h
>> @@ -641,7 +641,7 @@ static inline uint64_t udiv_qrnnd(uint64_t *r, uint64_t
>> n1,
>> uint64_t q;
>> asm("divq %4" : "=a"(q), "=d"(*r) : "0"(n0), "1"(n1), "rm"(d));
>> return q;
>> -#elif defined(__s390x__)
>> +#elif defined(__s390x__) && !defined(__clang__)
>> /* Need to use a TImode type to get an even register pair for DLGR. */
>> unsigned __int128 n = (unsigned __int128)n1 << 64 | n0;
>> asm("dlgr %0, %1" : "+r"(n) : "r"(d));
>
> Ok, so what's the deal with this patch now? Fix compilation now,
> optimize later?
>
> If yes, should I pick it as an s390x build fix (I plan to send a pull
> request later this week), or will the fpu maintainers pick it?
I'm planning to send a FPU PR tomorrow and I'll happily include either
version.
I'm personally minded to go with the patch that makes s390 (and others)
fall back to the generic CONFIG_INT128 code. The numbers Thomas gathered
didn't look like it was much difference either way.
Unless you *really* care about milking that last bit of performance out of
the s390 TCG back-end?
--
Alex Bennée
