Re: [PATCH] Reduce nr of ptr derefs in fs/jffs2/summary.c

[Andy Isaacson]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/