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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
