> > On Thumb-2 we found that the overhead of a function call was often > > smaller than the cost of lengthening branches in the caller. > > It turns out that, over a fair selection of applications, programmers > > tend to write "nice" sized functions. After inlining we have big nasty > > blocks of code that exceed the range of a short branch instruction. > > > > Of course a sufficiently smart reordering pass should be able to fix this > > by out-of-lining the big block of code. I'm pretty sure gcc can't > > currently do this. > > Hmm, we should be able to model this counting the number of edges > bypassing the call, right?
Something like that, yes. Ideally you'd want to factor in the size of the function, and the current length of those edges, at which point you've probably got sufficient information to make bb-reorder fix the problem once and for all ;-) Paul
