On Fri, 05 Nov 2010 13:41:45 -0400
Eric Paris <eparis@xxxxxxxxxx> wrote:
> On Sat, 2010-11-06 at 02:16 +0900, Tetsuo Handa wrote:
> > Tetsuo Handa wrote:
> > > Eric Paris wrote:
> > > > Interesting, is this a result of the compiler previously being able to
> > > > optimize the division since it could tell it was a power of 2 and now
> > > > that we have a private variable it can't? The patch can easily be
> > > > reverted without breaking anyone else....
> > >
> > I meant to say that it seems that GCC 3.x can optimize
> >
> > #define roundup(x, y) ((((x) + ((y) - 1)) / (y)) * (y))
> >
> > for roundup((long long), (const)) case but cannot optimize
> >
> > #define roundup(x, y) ( \
> > { \
> > typeof(y) __y = y; \
> > (((x) + (__y - 1)) / __y) * __y; \
> > } \
> > )
> >
> > for roundup((long long), (const)) case.
>
> I guess this is my fault (I'm not completely convinced) since my testing
> was done with gcc 4. I just retested to make sure that
> gcc-4.5.1-4.fc14.x86_64 is able to optimize both (and it does). Is the
> fact that it requires compiler optimizations for the code to build a
> good thing?
It does make us pretty fragile against future compiler versions, but we
do rely quite a lot on such compiler things. And things do break, such
as the several-month outbreak of calls to
you_cannot_kmalloc_that_much() a while back.
I wonder if there's some way of tricking gcc back into doing the right
thing here. Make __y const or something?
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
