lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 16 Aug 2009 12:14:25 +0300
From:	Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To:	Jiri Slaby <jirislaby@...il.com>
Cc:	Andi Kleen <andi@...stfloor.org>,
	"Robert P. J. Day" <rpjday@...shcourse.ca>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Make shr to divide by power of 2 (resend)

On (08/15/09 22:42), Jiri Slaby wrote:
> On 08/15/2009 04:12 PM, Sergey Senozhatsky wrote:
> > On (08/15/09 09:49), Robert P. J. Day wrote:
> >> On Sat, 15 Aug 2009, Jiri Slaby wrote:
> >>
> >>> On 08/15/2009 03:43 PM, Sergey Senozhatsky wrote:
> >>>> Make an arithmetic right shift to divide by power of 2.
> >>>
> >>> Why? Is out there a compiler not doing that?
> >>>
> >>> Seems like it should be rather converted to DIV_ROUND_UP.
> >>>
> > 
> >                                  
> > It was duscussed, so I'll just copy paste my answer.
> > On (08/08/09 09:35), Andi Kleen wrote:
> >> DIV should be always slower than a SHIFT.
> >>
> >> But it has nothing really to do with the CPU. The point is that the compiler
> >> always selects a suitable one by itself. Rewriting x / 2 to x >> 1 is
> >> one of the easiest exercises in compiler optimizations.
> >>
> >> The only case when the compiler cannot do this easily by itself is
> >> when the dividend is not a constant.
> 
> I think Andi (Cced again) meant divisor. When a divisor is constant, you
> can always transform division to some of subs/adds/muls/shifts.

Cced  Andi Kleen <andi@...stfloor.org>


> 
> >         int width = (vc->vc_font.width + 7) >> 3;
> > 
> >> That said -Os sometimes screws us up on this, but it's still not worth
> >> doing this change manually.
> >>
> > 
> > My point is that it should 'look the same'.
> > I mean there are 5
> >         int width = (vc->vc_font.width + 7) >> 3;
> > *not exactly this one, but vc->vc_font.width (+ 7)? >> 3
> > 
> > and _only_ one
> >         int width = (vc->vc_font.width + 7) / 8;
> > 
> > 
> >>   it does seem like a DIV_ROUND_UP would be better but perhaps another
> >> solution would be to define a meaningful macro name for that
> >> operation.  if that conversion is going to be done regularly, a macro
> >> with an informative name might be in order.  if it's a one-shot
> >> operation, though, not much point.
> >>
> > 
> > No, it's not a one-shot.
> > 
> > grep -c '>>' bitblit.c
> > 7
> 
> Then please use DIV_ROUND_UP macro (or whatever alias) all over the place.
> 

Sorry, once again (just to clear).

There are different shr/shl operations in bitblit.c. Like,
#1
cur_height = vc->vc_font.height >> 1
cur_height = (vc->vc_font.height << 1)/3;
c |= c >> 1;
u32 idx = vc->vc_font.width >> 3;
etc.

So, should I convert it to something like:
#2
cur_height = DIV_XXX(vc->vc_font.height, 2)
cur_height = DIV_XXX( MUL_XXX(vc->vc_font.height, 2), 3); or cur_height = DIV_XXX( (vc->vc_font.height * 2), 3);
c |= DIV_XXX(c, 1);
u32 idx = DIV_XXX(vc->vc_font.width, 8);

#1 is better-looking I think.

	Sergey
Download attachment "signature.asc" of type "application/pgp-signature" (316 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ