[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [qemu-s390x] [PATCH] include/fpu/softfloat: Fix compilation with Cla

From: Alex Bennée
Subject: Re: [qemu-s390x] [PATCH] include/fpu/softfloat: Fix compilation with Clang on s390x
Date: Wed, 16 Jan 2019 17:16:53 +0000
User-agent: mu4e 1.1.0; emacs 26.1.91

Cornelia Huck <address@hidden> writes:

> On Mon, 14 Jan 2019 13:12:35 +0100
> Thomas Huth <address@hidden> wrote:
>> 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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]