It seems to fail to do that when there are function calls of some kind between the accesses. I would say that that is a feature, not a misfeature in gcc.
However, code like
if(pike_frame->context.prog->event_handler) pike_frame->context.prog->event_handler(PROG_EVENT_GC_RECURSE);
for(q=0;q<(int)pike_frame->context.prog->num_variable_index;q++) { int d=pike_frame->context.prog->variable_index[q]; if(IDENTIFIER_IS_ALIAS(pike_frame->context.prog->identifiers[d]. identifier_flags)) { ... gc_mark_svalues( s, 1 ); ... } }
is not really all that optimal, since the memory access in the for-loop seems to be done once for each loop.
2e09: 8b 73 4c mov 0x4c(%ebx),%esi 2e0c: 83 c4 10 add $0x10,%esp 2e0f: 89 f1 mov %esi,%ecx 2e11: 47 inc %edi 2e12: 0f b7 41 6e movzwl 0x6e(%ecx),%eax 2e16: 39 c7 cmp %eax,%edi 2e18: 7c a6 jl 2dc0 <gc_mark_object_as_referenced+0x1c0>
/ Per Hedbor ()
Previous text:
2002-12-17 23:34: Subject: pike_frames vs. clone_object/destruct. (7.5)
If it doesn't optimize common subexpressions well then there's a whole lot of trivial optimizations we can do; long access chains are very common in the pike core.
/ Martin Stjernholm, Roxen IS