------- Comment #10 from carrot at google dot com 2009-05-05 15:32 ------- (In reply to comment #9) > (In reply to comment #8) > > Sorry for my ignorance to gcc. What types of instructions reload will add? > > Spilling and loading registers? and more? > > > That's pretty much it, but... Before register spilling, it must have used up all physical registers, including callee saved registers. Any saving of callee saved register should already have disabled this optimization.
> > > By reading the the implementation of thumb_far_jump_used_p() I can get the > > conclusion that if reload thinks there is a far jump, later pass won't > > change > > this decision. But if reload thinks there is no far jump, later pass still > > need > > to re-check the far jump existence and may change this decision. So if > > reload > > occasionally makes a wrong decision later pass should correct it, is it > > right? > > > > > Once reload has completed we can't change the decision as to whether or not LR > gets saved onto the stack or not. Unfortunately, that doesn't play well with > constant pools. We sometimes need to inline these, and that might cause > branches to be pushed out of range. Since we don't inline the pools until > after reload has completed, that's a major stumbling block. The current code > just isn't aware of these issues. > It looks like a bug in current code and my patch tries to exploit it. We should fix it by checking far jump (or thumb_force_lr_save) in reload pass only and simply get this computed value in later pass. It looks computing the exact limit is very difficult if not impossible. Could we simply use a predefined constant which is much much smaller than the far jump threshold as the limit? For example, use the constant 256 which is only 1/8 of the far jump threshold. I don't expect a larger function can have any chance to satisfy other conditions: leaf function and doesn't use any callee saved registers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
