lkml.org 
[lkml]   [2005]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Reduce nr of ptr derefs in fs/jffs2/summary.c
On Thu, Dec 15, 2005 at 11:55:05PM +0100, Jan Engelhardt wrote:
> >Benefits:
> > - micro speed optimization due to fewer pointer derefs
> > - generated code is slightly smaller
>
> Should not these two at best be done by the compiler?

The compiler cannot, in general, do CSE on pointer dereferences.
Consider the following snippet from fs/jffs2/summary.c, both before

610 sdrnt_ptr->type = c->summary->sum_list_head->d.type;
612 memcpy(sdrnt_ptr->name, c->summary->sum_list_head->d.name,
613 c->summary->sum_list_head->d.nsize);
615 wpage += JFFS2_SUMMARY_DIRENT_SIZE(c->summary->sum_list_head->d.nsize);

and after Jesper's patch:

611 sdrnt_ptr->type = temp->d.type;
613 memcpy(sdrnt_ptr->name, temp->d.name,
614 temp->d.nsize);
616 wpage += JFFS2_SUMMARY_DIRENT_SIZE(temp->d.nsize);

Assuming that memcpy is an out-of-line function, the compiler has to
handle the worst case, that it might modify c->summary->sum_list_head
and thus make the saved value stale. (In the specific case of memcpy
the compiler can take advantage of special knowledge about the function,
and it's probably inline anyways, so this *particular* example is not
real; but it's a nice clean classroom example.)

But a human *can* make the obvious leap and tell the compiler that the
value can be computed once and then saved. And besides, isn't the code
just *much* nicer to look at, above?

-andy
-
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/

\
 
 \ /
  Last update: 2005-12-16 04:37    [W:0.063 / U:0.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site