lkml.org 
[lkml]   [2008]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] consolidate all within() implementations
From
Date
Peter Zijlstra <a.p.zijlstra@chello.nl> wrote on 21.05.2008 12:48:52:

> On Wed, 2008-05-21 at 12:33 +0200, Peter 1 Oberparleiter wrote:
> > Peter Zijlstra <a.p.zijlstra@chello.nl> wrote on 21.05.2008 12:04:26:

> peter@lappy:~/tmp$ gcc -S -Os cmp*.c
> peter@lappy:~/tmp$ ls -la cmp*.o
> -rw-r--r-- 1 peter peter 752 2008-05-21 12:43 cmp2.o
> -rw-r--r-- 1 peter peter 743 2008-05-21 12:43 cmp.o

Yeah, but!

[oberpar@local cmp]$ gcc -c -O2 cmp*.c
[oberpar@local cmp]$ ls -la cmp*.o
-rw-r--r-- 1 oberpar oberpar 1352 May 21 15:40 cmp2.o
-rw-r--r-- 1 oberpar oberpar 1408 May 21 15:40 cmp.o

:)

> Also look at the .s output and notice mine doesn't have any additional
> branches ;-)

It really boils down to the question whether you want to trade
a bit of obviousness for a bit of efficiency/clever programming.
I vote for keeping the former.

> > > static inline int
> > > addr_within(const void *add, const void *start, const void *end)
> > > {
> > > return addr_within_len(addr, start,
> > > (unsigned long)end - (unsigned long)start);
> > > }
> >
> > For empty ranges (start > end), this produces different (less
expected)
> > results than the previous version.
>
> agreed, do we care about those?

Why not plan for the unexpected when it comes at little cost?


Regards,
Peter


\
 
 \ /
  Last update: 2008-05-21 15:53    [W:0.048 / U:0.528 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site