AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jochen Rollwagen <joro-2013-zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org>
To: "Michel Dänzer" <michel-otUistvHUpPR7s880joybQ@public.gmane.org>
Cc: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Subject: Re: [PATCH xf86-video-ati] Replace loop with clz to calculate log base 2 on non-x86 platforms in radeon.h
Date: Fri, 2 Dec 2016 10:31:20 +0100	[thread overview]
Message-ID: <58413F68.70807@t-online.de> (raw)
In-Reply-To: <b61bde0b-5120-5eaa-4243-18e30091ef86-otUistvHUpPR7s880joybQ@public.gmane.org>

Am 01.12.2016 um 01:57 schrieb Michel Dänzer:
> On 01/12/16 02:52 AM, Jochen Rollwagen wrote:
>> Am 29.11.2016 um 08:32 schrieb Michel Dänzer:
>>> On 29/11/16 03:18 AM, Jochen Rollwagen wrote:
>>>> This commit replaces the loop for calculating log base 2 for
>>>> non-x86-platforms in radeon.h with a clz (count leading zeroes)-based
>>>> version to simplify the code and, well, eliminate the loop.
>>>> Note: There’s no check for val=0 case, since x86-bsr is undefined for
>>>> that case too, that should be okay.
>>>> ---
>>>>   src/radeon.h |    7 +++----
>>>>   1 file changed, 3 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/src/radeon.h b/src/radeon.h
>>>> index cbc7866..b1a1ce0 100644
>>>> --- a/src/radeon.h
>>>> +++ b/src/radeon.h
>>>> @@ -933,17 +933,16 @@ enum {
>>>>   static __inline__ int
>>>>   RADEONLog2(int val)
>>>>   {
>>>> -    int bits;
>>>>   #if (defined __i386__ || defined __x86_64__) && (defined __GNUC__)
>>>> +    int bits;
>>>> +
>>>>       __asm volatile("bsrl    %1, %0"
>>>>           : "=r" (bits)
>>>>           : "c" (val)
>>>>       );
>>>>       return bits;
>>>>   #else
>>>> -    for (bits = 0; val != 0; val >>= 1, ++bits)
>>>> -        ;
>>>> -    return bits - 1;
>>>> +    return (31 - __builtin_clz(val));
>>>>   #endif
>>>>   }
>>> Any reason for not using __builtin_clz on x86 as well? AFAICT both gcc
>>> and clang seem to generate more or less the same code with that as with
>>> the inline assembly.
>>>
>>>
>> I guess not. According to
>> http://stackoverflow.com/questions/9353973/implementation-of-builtin-clz
>> "bsr and clz are related but different.
>>
>> On x86 for clz gcc (-O2) generates:
>>
>> bsrl %edi, %eax
>> xorl $31, %eax
>> ret "
> That's not what I'm seeing. Have you compared the code generated by your
> compiler in both cases?
>
>
Well, I'm on a powerpc platform, the generated code looks like this:

RADEONLog2:
     stwu %r1,-16(%r1)
     cntlzw %r3,%r3
     subfic %r3,%r3,31
     addi %r1,%r1,16
     blr

Straightforward enough.

But i guess you’re right, the generated code is similar enough to 
justify a general approach without platform-specific inline assembler 
and leaving the rest to the compiler.

  I'll post V2 of the patch.


_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

      parent reply	other threads:[~2016-12-02  9:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-24 18:00 [PATCH] xf86-video-ati: Fix build for xserver < 1.13 Jochen Rollwagen
     [not found] ` <58372ADA.8040009-zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org>
2016-11-25  9:14   ` Michel Dänzer
     [not found]     ` <dd911a26-9976-6570-f5ac-5efe67e27928-otUistvHUpPR7s880joybQ@public.gmane.org>
2016-11-25 10:00       ` [PATCH xf86-video-ati] Use finer-grained pointer types in mem copying functions Jochen Rollwagen
     [not found]         ` <58380BA2.3060006-zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org>
2016-11-28  9:43           ` Michel Dänzer
     [not found]             ` <f3c04cd0-06b0-85c4-48d0-1bfbdd98dfdf-otUistvHUpPR7s880joybQ@public.gmane.org>
2016-11-28 18:18               ` [PATCH xf86-video-ati] Replace loop with clz to calculate log base 2 on non-x86 platforms in radeon.h Jochen Rollwagen
     [not found]                 ` <583C74DA.2070701-zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org>
2016-11-29  7:32                   ` Michel Dänzer
     [not found]                     ` <e3556fa8-39eb-6b1d-9d71-316c23bff9ea-otUistvHUpPR7s880joybQ@public.gmane.org>
2016-11-30 17:52                       ` Jochen Rollwagen
     [not found]                         ` <583F11F6.7000005-zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org>
2016-12-01  0:57                           ` Michel Dänzer
     [not found]                             ` <b61bde0b-5120-5eaa-4243-18e30091ef86-otUistvHUpPR7s880joybQ@public.gmane.org>
2016-12-02  9:31                               ` Jochen Rollwagen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=58413F68.70807@t-online.de \
    --to=joro-2013-zqrnuxuvxa0b1svskn2v4q@public.gmane.org \
    --cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=michel-otUistvHUpPR7s880joybQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox