[Bug target/54063] [4.8 regression] on powerpc64 gcc 4.8 generates larger code for global variable accesses than gcc 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54063 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-04 13:05:05 UTC --- While the memory load is split already during reload, the set for head is only split during split2 pass, which is after postreload_cse (and gcse2) which are the last CSE-ish passes I think. So perhaps you could tweak machine reorg pass to handle some of the easy cases, or what exactly is the reason for running split2 after postreload CSE instead of before it?
[Bug target/54063] [4.8 regression] on powerpc64 gcc 4.8 generates larger code for global variable accesses than gcc 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54063 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-09-19 Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-19 13:56:43 UTC --- So, WONTFIX?
[Bug target/54063] [4.8 regression] on powerpc64 gcc 4.8 generates larger code for global variable accesses than gcc 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54063 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug target/54063] [4.8 regression] on powerpc64 gcc 4.8 generates larger code for global variable accesses than gcc 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54063 Alan Modra amodra at gmail dot com changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #2 from Alan Modra amodra at gmail dot com 2012-07-23 02:13:53 UTC --- Gultiy as charged. Not splitting the address early loses some opportunities for common subexpression eliminiation. However, splitting the address early a) is inconsistent with the treatment of other powerpc addresses b) can result in incorrect code and/or require hacks (that pessimise scheduling) to prevent incorrect code in other cases, eg. indirect function call sequence. c) can result in silly uses of call-saved regs for the high part of an address calculation around a call or outside of a loop, when it would be far better to just recalculate an address thus freeing the reg for better uses. d) can allow the high/low parts to move in ways that result in the linker disabling optimisation of these sequences for the entire object file (or generating bad code if you have an old linker). eg. another kernel case where the low part moved to a different (hot/cold) section. Overall, I think we get better code by *not* splitting early, particularly for larger functions that run into (c).
[Bug target/54063] [4.8 regression] on powerpc64 gcc 4.8 generates larger code for global variable accesses than gcc 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54063 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||amodra at gcc dot gnu.org --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2012-07-21 18:47:30 UTC --- It's caused by Alan Modra's rs6000 toc reference rtl again change in r187699: http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00696.html http://gcc.gnu.org/ml/gcc-patches/2012-05/msg6.html Here's the diff in output from r187698 and r187699 on this test case: --- glovar.s-r1876982012-07-21 20:31:01.0 +0200 +++ glovar.s-r1876992012-07-21 20:35:59.0 +0200 @@ -11,8 +11,9 @@ .previous .type lookup, @function .L.lookup: + addis 10,2,.LANCHOR0@toc@ha addis 8,2,.LANCHOR0@toc@ha - ld 9,.LANCHOR0@toc@l(8) + ld 9,.LANCHOR0@toc@l(10) addi 8,8,.LANCHOR0@toc@l cmpd 7,9,8 bne 7,.L4
