On 2019-01-16 18:16, Alex Bennée wrote:
>
> 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?
I don't think that anybody buys a mainframe for this special case ;-)
I'd go with the !defined(__clang__) patch above.
Thomas
