[Bug bootstrap/68404] [6 Regression] PGO/LTO bootstrap failure on ppc64le

wschmidt at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Fri Feb 5 23:29:00 GMT 2016


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404

--- Comment #9 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
Finally got back to this for a bit.  I've tracked the problem down to the
register renaming pass.  I suspect it's having trouble with the
fusion_gpr_load_di pattern:

(insn 452 236 243 19 (set (reg:DI 9 9)
        (unspec:DI [
                (zero_extend:DI (mem:SI (plus:DI (plus:DI (reg:DI 9 9 [335])
                                (const_int 65536 [0x10000]))
                            (const_int -21428 [0xffffffffffffac4c])) [160
MEM[(\
struct target_reload *)_130 + 44108B]+0 S4 A32]))
            ] UNSPEC_FUSION_GPR))
/home/wschmidt/gcc/gcc-mainline-test/gcc/call\
er-save.c:141 757 {fusion_gpr_load_di}
     (nil))

At a guess, the (mem (plus (plus (reg ... pattern might have caught it by
surprise, making the reference to (reg:DI 9 9) get missed in the analysis. 
Prior to the renaming pass, the feeding insn 217 defines (reg:DI 9 9) as
expected:

(insn 217 214 218 17 (set (reg:DI 9 9 [335])
        (plus:DI (reg/f:DI 9 9 [orig:338 _29 ] [338])
            (reg:DI 26 26 [orig:185 _59 ] [185])))
/home/wschmidt/gcc/gcc-mainl\
ine-test/gcc/caller-save.c:140 81 {*adddi3}
     (nil))

Following renaming, it now defines (reg:DI 3 3) instead, causing the
fusion_gpr_load_di pattern to be fed by a different definition of (reg:DI 9 9),
causing the problem:

(insn 217 214 218 17 (set (reg:DI 3 3 [335])
        (plus:DI (reg/f:DI 28 28 [orig:338 _29 ] [338])
            (reg:DI 26 26 [orig:185 _59 ] [185])))
/home/wschmidt/gcc/gcc-mainl\
ine-test/gcc/caller-save.c:140 81 {*adddi3}
     (nil))

Recording this here as I may not get back to it before I leave on vacation for
a week.


More information about the Gcc-bugs mailing list