[Bug target/38570] [arm] -mthumb generates sub-optimal prolog/epilog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570 Wilco changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #13 from Wilco --- Close
[Bug target/38570] [arm] -mthumb generates sub-optimal prolog/epilog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570 Wilco changed: What|Removed |Added CC||wilco at gcc dot gnu.org --- Comment #12 from Wilco --- This has been fixed since at least GCC5.4.1: https://www.godbolt.org/z/BlaE1o
[Bug target/38570] [arm] -mthumb generates sub-optimal prolog/epilog
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
[Bug target/38570] [arm] -mthumb generates sub-optimal prolog/epilog
--- Comment #11 from steven at gcc dot gnu dot org 2009-06-22 16:41 --- IIUC comment #8, this bug depends on bug 29336. -- steven at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||29336 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
[Bug target/38570] [arm] -mthumb generates sub-optimal prolog/epilog
--- 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
[Bug target/38570] [arm] -mthumb generates sub-optimal prolog/epilog
--- Comment #9 from rearnsha at gcc dot gnu dot org 2009-05-05 10:06 --- (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... > 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. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
[Bug target/38570] [arm] -mthumb generates sub-optimal prolog/epilog
--- Comment #8 from carrot at google dot com 2009-05-04 10:08 --- Sorry for my ignorance to gcc. What types of instructions reload will add? Spilling and loading registers? and more? 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? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
[Bug target/38570] [arm] -mthumb generates sub-optimal prolog/epilog
--- Comment #7 from rearnsha at gcc dot gnu dot org 2009-05-04 09:41 --- (In reply to comment #6) > We can compute the maximum possible function length first. If the length is > not > large enough far jump is not necessary, and we can do this optimization > safely. > No, it's not that easy, since reload can add instructions. Realistically, there is a finite limit beyond which even reload couldn't generate sufficiently large numbers of instructions to cause failure, but it's hard to *prove* what that lower bound is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
[Bug target/38570] [arm] -mthumb generates sub-optimal prolog/epilog
--- Comment #6 from carrot at google dot com 2009-05-04 02:21 --- We can compute the maximum possible function length first. If the length is not large enough far jump is not necessary, and we can do this optimization safely. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
[Bug target/38570] [arm] -mthumb generates sub-optimal prolog/epilog
--- Comment #5 from ramana at gcc dot gnu dot org 2009-05-01 08:39 --- *** Bug 39989 has been marked as a duplicate of this bug. *** -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||carrot at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
[Bug target/38570] [arm] -mthumb generates sub-optimal prolog/epilog
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-30 10:53:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
