On Mon, Nov 12, 2007 at 11:58:43AM -0500, Jakub Jelinek wrote:
quoted text
> On Sun, Nov 11, 2007 at 07:48:29AM +0100, Adrian Bunk wrote:
> > The gcc from svn that will become gcc 4.3 generates libgcc calls in 
> > cases like the following (on 32bit architectures):
> > 
> > <--  snip  -->
> > 
> > static inline void timespec_add_ns(struct timespec *a, u64 ns)
> > {
> > ...
> >         while(ns >= NSEC_PER_SEC) {
> >                 ns -= NSEC_PER_SEC;
> >                 a->tv_sec++;
> >         }
> > ...
> > 
> > <--  snip  -->
> 
> Blindly using -fno-tree-scev-cprop just to get rid of one case where
> this turns out to be a pessimization when kernel knows ns is usually very
> small is IMHO a wrong thing, you'd lose many cases where this optimization
> can actually improve performance.

It's not about performance, it's about a build error.

quoted text
> Instead, for this exact case just
> add an optimization barrier to avoid gcc doing this.
> Adding asm ("" : "=r" (ns) : "0" (ns)); (or hide it in some macro) into the
> loop will do the job just fine.

The problem is that this is very fragile - imagine what might happen 
when a frequently used struct member gets changed from int to u64.

After all, when looking at current practice, the kernel will support 
being built with gcc 4.3 until 2013 or 2014.

quoted text
> 	Jakub

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/