[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #32 from Andrey Belevantsev abel at gcc dot gnu.org 2013-02-19 13:50:59 UTC --- Author: abel Date: Tue Feb 19 13:50:50 2013 New Revision: 196137 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196137 Log: 2012-02-19 Andrey Belevantsev a...@ispras.ru PR middle-end/55889 * sel-sched.c: Include ira.h. (implicit_clobber_conflict_p): New function. (moveup_expr): Use it. * Makefile.in (sel-sched.o): Depend on ira.h. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/sel-sched.c
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 Andrey Belevantsev abel at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #33 from Andrey Belevantsev abel at gcc dot gnu.org 2013-02-19 13:54:00 UTC --- Fixed on trunk but is latent on 4.7 and I guess 4.6, since the introduction of register pressure sensitive code.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 Andrey Belevantsev abel at gcc dot gnu.org changed: What|Removed |Added Attachment #29146|0 |1 is obsolete|| Attachment #29202|0 |1 is obsolete|| --- Comment #30 from Andrey Belevantsev abel at gcc dot gnu.org 2013-02-15 13:47:31 UTC --- Created attachment 29466 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29466 proposed patch David, can you try the attached patch? It fixes the test case for me. If it works for you, I'll test it on x86-64 and ia64. Testing on powerpc-aix would be great, if you have some time.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #31 from David Edelsohn dje at gcc dot gnu.org 2013-02-15 16:15:19 UTC --- With the patch, the testcase no longer ICEs when compiled on powerpc-aix.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC||vmakarov at redhat dot com --- Comment #29 from Vladimir Makarov vmakarov at redhat dot com 2013-02-14 16:48:24 UTC --- (In reply to comment #28) (In reply to comment #27) (In reply to comment #26) You are right, your suggestions is what I sketched in comment #21 as choices 1 or 2. Sorry for my unclear expalanation of what was actually happening. I don't have a problem with making sel-sched have extra checks when renaming registers before reload, which will make us notice a not obvious extra dependence and avoid renaming properly, as now we've figured out these dependences don't follow immediately from the RTL. I just want an extra opinion on whether such unexpected dependencies arising when a target (hard) register is replaced by a pseudo register should be normal within GCC, or do we attribute such dependencies only to the register pressure scheduling mode. FWIW, I would rather agree with the latter than with the former. I guess you can not fully assume that dependencies are created only from RTL data flow. There are cases (besides pressure sensitive scheduling case mentioned here) when dependencies are still created for other reasons different from RTL data flow. I'd look at the dependencies as constraints resulting in correct and *desirable* insn schedule. Although overwhelming majority of them are created from RTL data flow analysis. I agree with you in general, it's just this case of having extra dependencies because an LHS hard register was substituted to a pseudo is non-intuitive to me. I am not aware of other similar cases when the other dependency reasons you mention kick in after such transformation. For example, additional dependencies can be created when queues are too long to speed up insn scheduling in some patalogical cases. The probability that it happens is small but it still happens and selective scheduler can crash in this case too. So I'll try going with the minimal fix of tracking only this particular case (of newly created implicit clobbers) in the selective scheduler. Btw, does the code calculating implicit clobbers via ira_implicitly_set_insn_hard_regs were planned just for the pressure sensitive scheduling or also for the general case? It looks like it is needed for the former but it is calculated for the latter. It was done to solve (or at least decrease the probability) reload crashes (reload can not find a spill register) when the first insn scheduling is used.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #28 from Andrey Belevantsev abel at gcc dot gnu.org 2013-02-14 06:11:21 UTC --- (In reply to comment #27) (In reply to comment #26) You are right, your suggestions is what I sketched in comment #21 as choices 1 or 2. Sorry for my unclear expalanation of what was actually happening. I don't have a problem with making sel-sched have extra checks when renaming registers before reload, which will make us notice a not obvious extra dependence and avoid renaming properly, as now we've figured out these dependences don't follow immediately from the RTL. I just want an extra opinion on whether such unexpected dependencies arising when a target (hard) register is replaced by a pseudo register should be normal within GCC, or do we attribute such dependencies only to the register pressure scheduling mode. FWIW, I would rather agree with the latter than with the former. I guess you can not fully assume that dependencies are created only from RTL data flow. There are cases (besides pressure sensitive scheduling case mentioned here) when dependencies are still created for other reasons different from RTL data flow. I'd look at the dependencies as constraints resulting in correct and *desirable* insn schedule. Although overwhelming majority of them are created from RTL data flow analysis. I agree with you in general, it's just this case of having extra dependencies because an LHS hard register was substituted to a pseudo is non-intuitive to me. I am not aware of other similar cases when the other dependency reasons you mention kick in after such transformation. So I'll try going with the minimal fix of tracking only this particular case (of newly created implicit clobbers) in the selective scheduler. Btw, does the code calculating implicit clobbers via ira_implicitly_set_insn_hard_regs were planned just for the pressure sensitive scheduling or also for the general case? It looks like it is needed for the former but it is calculated for the latter.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #27 from Vladimir Makarov vmakarov at gcc dot gnu.org 2013-02-06 21:36:59 UTC --- (In reply to comment #26) You are right, your suggestions is what I sketched in comment #21 as choices 1 or 2. Sorry for my unclear expalanation of what was actually happening. I don't have a problem with making sel-sched have extra checks when renaming registers before reload, which will make us notice a not obvious extra dependence and avoid renaming properly, as now we've figured out these dependences don't follow immediately from the RTL. I just want an extra opinion on whether such unexpected dependencies arising when a target (hard) register is replaced by a pseudo register should be normal within GCC, or do we attribute such dependencies only to the register pressure scheduling mode. FWIW, I would rather agree with the latter than with the former. I guess you can not fully assume that dependencies are created only from RTL data flow. There are cases (besides pressure sensitive scheduling case mentioned here) when dependencies are still created for other reasons different from RTL data flow. I'd look at the dependencies as constraints resulting in correct and *desirable* insn schedule. Although overwhelming majority of them are created from RTL data flow analysis.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #26 from Andrey Belevantsev abel at gcc dot gnu.org 2013-02-01 12:22:05 UTC --- You are right, your suggestions is what I sketched in comment #21 as choices 1 or 2. Sorry for my unclear expalanation of what was actually happening. I don't have a problem with making sel-sched have extra checks when renaming registers before reload, which will make us notice a not obvious extra dependence and avoid renaming properly, as now we've figured out these dependences don't follow immediately from the RTL. I just want an extra opinion on whether such unexpected dependencies arising when a target (hard) register is replaced by a pseudo register should be normal within GCC, or do we attribute such dependencies only to the register pressure scheduling mode. FWIW, I would rather agree with the latter than with the former.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #25 from David Edelsohn dje at gcc dot gnu.org 2013-01-31 17:50:07 UTC --- 15: r3 = rhs0 17: r3 = rhs1 (r3, ..., !r65) 20: use(r3) 24: r3 = rhs2 26: r3 = rhs3 (r3, ..., !r65) 29: use(r3) Insn 24 does not depend on r65 and can move above insn 17. Either schedule pressure pass should not introduce the fake and inaccurate dependency or selective scheduler should ignore these type of fake dependencies when verifying code motion is safe.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #23 from Andrey Belevantsev abel at gcc dot gnu.org 2013-01-24 13:37:05 UTC --- You are right from the target maintainer point of view, as you understand what really happens in the code. But this is not what the compiler sees as the relations between insns you are talking about are not always expressed in the RTL. Consider insns 17 and 23, not looking at the other insns. From their RTL there is no clear control and data dependencies at all, they don't mention the same register or memory. (You are saying that insn 17 represents a call but it is not clear from its representation, too.) As I mentioned, the only reason insn 23 gets dependent on insn 17 is that ira_implicitly_set_insn_hard_regs kicks in and says, we have a LINK_REGS alternative in insn 23, and the corresponding reg class is small, let us consider insn 23 clobber reg 65 (LR), and because insn 17 also clobbers reg 65 you get a dependency. This was added with the sched-pressure code, which is why I CC'd Vlad. And this issue is not sel-sched specific, you need just to disable the if (! reload_completed) at sched-deps.c:2805 with e.g. INSN_UID (insn) != 23, and remove the -fselective-scheduling flag, and you will see the regular scheduler happily lift off insn 23 through insn 17 and place it before insn 17, as there is no dependency that can be guessed by the regular sched-deps analysis just by looking at the RTL of those insns. If you want to have such a dependency, I'd suggest to add some specific clobber as it is done for insn 17. This will fix this particular issue, but in general the question on the register renaming in the sel-sched remains, as we just see 17: r3 = rhs1 20: use(r3) 24: r3 = rhs2 and we assume we can do new1: r150 = rhs2 17: r3 = rhs1 20: use(r3) new2: r3 = r150 and this will not create random dependencies between insn new1 and insn 17 as it happens now. Again, there is no dependencies that can be seen from the RTL that prevent us from doing so.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #24 from David Edelsohn dje at gcc dot gnu.org 2013-01-24 16:37:23 UTC --- It does not matter if the scheduler knows that insns 17, 20, 26 and 29 really are calls. The clobbers express everything important. insn 15 produces r3. insn 16 produces r4. insn 17 consumes r3, r4 and produces r3 and clobbers r4. insn 20 consumes r3. insn 23 produces r148. insn 24 produces r3. insn 25 consumes r148 and produces r4. insn 26 consumes r3, r4 and produces r3 and clobber r4. insn 29 consumes r3. And, yes, insn 23 can be moved before insn 17. It simply requires an additional, temporary hard register not clobbered by insn 17 that will be copied to r4 in insn 25. But I am pointing out that one can track that insn 26 depends on insn 25 and insn 25 depends on insn 23 through the dataflow graph. Again, nothing says that insn 23 cannot be hoisted above insn 17. The only instructions that clobber r65 (LR) are insns 17 and 26. I do not understand your comments or what information you think is missing or what is causing the ICE. It seems more that there is something wrong with the assert causing the ICE and/or some data structure not set / updated correctly in sel-sched.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889
Andrey Belevantsev abel at gcc dot gnu.org changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment #21 from Andrey Belevantsev abel at gcc dot gnu.org 2013-01-23
11:11:22 UTC ---
Thanks again folks, it's much simpler with gdb. So the reason of the
difference that shows up in the ICE is the ira_implicitly_set_insn_hard_regs
function. Recall that we have insns 23 and 24 like this:
23: r148:SI=[unspec[`*LC..2',%2:SI] 44]
24: %3:SI=[unspec[`*LCM..2',%2:SI] 44]
and insn 17 like this:
17: {%3:SI=unspec[%3:SI,%4:SI] 25;clobber %0:SI;clobber %4:SI;clobber
%5:SI;clobber %11:SI;clobber %0:CC;clobber lr:SI;}
The dependency between insns 23 and 17 is because insn 17 clobbers reg 65 (I
guess it is lr in the dump). When analyzing insn 23,
ira_implicitly_set_insn_hard_regs is called and it notices we have a pseudo-reg
148. The function attempts to restrict the insn movement by marking the
registers that might be required by the strict alternatives of the insn as
implicit clobbers. For insn 23 it marks reg 65 from LINK_REGS ('l' constraint)
and reg 66 from CTR_REGS ('c' constraint AFAIR). Now we have an
anti-dependency via clobbering reg 65 with insn 17.
Insn 24 already has the hard register assigned (%3), so the above logic does
not apply and we don't get the implicit clobbers on this insn and thus a
dependency with insn 17.
In short, the implicit clobbers thing disagrees with the assumption sel-sched
mades: that renaming a hard register to a pseudo is always possible given that
the resulting insn is recognized and will never create extra dependencies.
So the choices we have are as follows:
1) make the if (! reload_completed) at sched-deps.c:2805 also conditional on
-fsched-pressure and make sel-sched incompatible with -fsched-pressure by
disallowing to specify both options at the same time. That is,
-fselective-scheduling will disable -fsched-pressure with a note to the user.
2) make the selective scheduler account for the situation when renaming a hard
register to a pseudo register before reload with sched-pressure enabled might
create extra dependencies, then insn 24 will never be considered for renaming
and the problem will be fixed.
I can do either 1 or 2, no problem with any of those given enough time until
4.8.
Thoughts?
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889
--- Comment #22 from David Edelsohn dje at gcc dot gnu.org 2013-01-24
02:35:33 UTC ---
I don't understand your analysis. Prior to sched1, the pr50907.c.205r.asmcons
RTL dump looks like:
(insn 15 14 16 2 (set (reg:SI 3 3)
(mem/u/c:SI (unspec:SI [
(symbol_ref:SI (*LCM..0) [flags 0x2])
(reg:SI 2 2)
] UNSPEC_TOCREL) [0 S4 A8]))
/nasfarm/dje/src/src/gcc/testsuite/
gcc.dg/tree-prof/pr50907.c:5 346 {*movsi_internal1}
(nil))
(insn 16 15 17 2 (set (reg:SI 4 4)
(mem/u/c:SI (unspec:SI [
(symbol_ref/u:SI (*LC..0) [flags 0x2])
(reg:SI 2 2)
] UNSPEC_TOCREL) [0 S4 A8]))
/nasfarm/dje/src/src/gcc/testsuite/
gcc.dg/tree-prof/pr50907.c:5 346 {*movsi_internal1}
(nil))
(insn 17 16 18 2 (parallel [
(set (reg:SI 3 3)
(unspec:SI [
(reg:SI 3 3)
(reg:SI 4 4)
] UNSPEC_TLSTLS))
(clobber (reg:SI 0 0))
(clobber (reg:SI 4 4))
(clobber (reg:SI 5 5))
(clobber (reg:SI 11 11))
(clobber (reg:CC 68 0))
(clobber (reg:SI 65 lr))
]) /nasfarm/dje/src/src/gcc/testsuite/gcc.dg/tree-prof/pr50907.c:5 443
{
tls_get_addr_internalsi}
(expr_list:REG_DEAD (reg:SI 4 4)
(expr_list:REG_UNUSED (reg:CC 68 0)
(expr_list:REG_UNUSED (reg:SI 65 lr)
(expr_list:REG_UNUSED (reg:SI 11 11)
(expr_list:REG_UNUSED (reg:SI 5 5)
(expr_list:REG_UNUSED (reg:SI 4 4)
(expr_list:REG_UNUSED (reg:SI 0 0)
(nil)
(insn 20 18 21 2 (set (reg/f:SI 144 [ __gcov_indirect_call_counters ])
(mem/u/f/c:SI (reg:SI 3 3) [0 __gcov_indirect_call_counters+0 S4 A32]))
346 {*movsi_internal1}
(expr_list:REG_DEAD (reg:SI 3 3)
(nil)))
(insn 23 22 24 2 (set (reg:SI 148)
(mem/u/c:SI (unspec:SI [
(symbol_ref/u:SI (*LC..2) [flags 0x2])
(reg:SI 2 2)
] UNSPEC_TOCREL) [0 S4 A8]))
/nasfarm/dje/src/src/gcc/testsuite/
gcc.dg/tree-prof/pr50907.c:5 346 {*movsi_internal1}
(nil))
(insn 24 23 25 2 (set (reg:SI 3 3)
(mem/u/c:SI (unspec:SI [
(symbol_ref:SI (*LCM..2) [flags 0x2])
(reg:SI 2 2)
] UNSPEC_TOCREL) [0 S4 A8]))
/nasfarm/dje/src/src/gcc/testsuite/
gcc.dg/tree-prof/pr50907.c:5 346 {*movsi_internal1}
(nil))
(insn 25 24 26 2 (set (reg:SI 4 4)
(reg:SI 148))
/nasfarm/dje/src/src/gcc/testsuite/gcc.dg/tree-prof/pr5090
7.c:5 346 {*movsi_internal1}
(nil))
(insn 26 25 27 2 (parallel [
(set (reg:SI 3 3)
(unspec:SI [
(reg:SI 3 3)
(reg:SI 4 4)
] UNSPEC_TLSTLS))
(clobber (reg:SI 0 0))
(clobber (reg:SI 4 4))
(clobber (reg:SI 5 5))
(clobber (reg:SI 11 11))
(clobber (reg:CC 68 0))
(clobber (reg:SI 65 lr))
]) /nasfarm/dje/src/src/gcc/testsuite/gcc.dg/tree-prof/pr50907.c:5 443
{
tls_get_addr_internalsi}
(expr_list:REG_DEAD (reg:SI 4 4)
(expr_list:REG_UNUSED (reg:CC 68 0)
(expr_list:REG_UNUSED (reg:SI 65 lr)
(expr_list:REG_UNUSED (reg:SI 11 11)
(expr_list:REG_UNUSED (reg:SI 5 5)
(expr_list:REG_UNUSED (reg:SI 4 4)
(expr_list:REG_UNUSED (reg:SI 0 0)
(nil)
(insn 29 27 30 2 (set (reg/f:SI 150 [ __gcov_indirect_call_callee ])
(mem/f/c:SI (reg:SI 3 3) [0 __gcov_indirect_call_callee+0 S4 A32])) 346
{*movsi_internal1}
(expr_list:REG_DEAD (reg:SI 3 3)
(nil)))
(insn 30 29 31 2 (set (reg:SI 3 3)
(reg/f:SI 144 [ __gcov_indirect_call_counters ])) 346
{*movsi_internal1}
(expr_list:REG_DEAD (reg/f:SI 144 [ __gcov_indirect_call_counters ])
(nil)))
(insn 31 30 32 2 (set (reg:DI 4 4)
(const_int 0 [0])) 367 {*movdi_internal32}
(nil))
Insns 15 and 16 feed into the TLS call of insn 17. Insns 23 an 24 feed into
the TLS call of insn 26.
The combine pass converted the original pseudos of insns 13, 14 and 21 into
hard registers. It also combined insns 22 and 24, but left the result in pseudo
r148. Insn 25 moves pseudo r148 into hard register r4, which is used in insn
26.
I do not understand why r65 (LR) is involved or critical, and I do not
understand how the selective scheduler thinks it can move any of those
instructions past one another with the clear control and data dependencies.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #11 from Andrey Belevantsev abel at gcc dot gnu.org 2013-01-21 10:15:31 UTC --- (In reply to comment #10) Neither insn 24/145 nor insn 28 move through insn 17. The two UNSPEC 44 insn (LC..2,, LCM..2) are inputs to insn 17. The pseudos are moved into r3 and r4, which are the inputs to insn 17. You mean insn 23, not insn 28, right? I'm not sure how insns 23/24 could be inputs to insn 17, as they move up through insn 17. I don't see full RTL so I'm guessing here. Unfortunately, libbacktrace didn't work for the dump you provided, so I only see that for insn 23 we generate a general dependency meaning that it is not connected to lhs or rhs of the insn, but I don't know where exactly it comes from. We do not generate such dependency for insn 24, while they differ only in lhs -- the former having a pseudo, the latter a hard register r3. I think this could be fixed by making the same kind of dependency for insn 24, but I'm unable to make the compiler generate it, as to get insn 17 I need TLS support not available in the cross compiler. In general, would you allow insn 24 to move past insn 17 with the new register or does it have to be r3 in insn 24?
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-21 12:53:09 UTC --- I've tried to reproduce this with a cross compiler (without cross binutils) on x86_64-linux host, but it ICEs elsewhere: ../configure --target powerpc-ibm-aix5.3.1 --disable-bootstrap --enable-languages=c make cd gcc sed -i -e 's/^.*HAVE_AS_TLS.*$/#define HAVE_AS_TLS 1/' auto-host.h make cc1 ./cc1 -O -fschedule-insns -fselective-scheduling -fpic -fprofile-generate pr50907.c -maix32 But this ICEs in: #0 0x00cca50b in get_pool_constant (addr=0x71aa7ee0) at ../../gcc/varasm.c:3631 #1 0x00ce285c in rs6000_delegitimize_address (orig_x=0x71a7aa20) at ../../gcc/config/rs6000/rs6000.c:5834 #2 0x00a04b0e in avoid_constant_pool_reference (x=0x71a7aa38) at ../../gcc/simplify-rtx.c:220 #3 0x00e7c211 in equiv_constant (x=0x71a7aa38) at ../../gcc/cse.c:3797 #4 0x00e7a811 in fold_rtx (x=0x71a7aa38, insn=0x71aa6750) at ../../gcc/cse.c:3122 #5 0x00e7dd3c in cse_insn (insn=0x71aa6750) at ../../gcc/cse.c:4573 #6 0x00e833f1 in cse_extended_basic_block (ebb_data=0x7fffdf40) at ../../gcc/cse.c:6405 #7 0x00e83990 in cse_main (f=0x71a89200, nregs=190) at ../../gcc/cse.c:6583 #8 0x00e8569c in rest_of_handle_cse () at ../../gcc/cse.c:7433 on (symbol_ref:SI (*LCM..0) [flags 0x2]) (note, not CONSTANT_POOL_ADDRESS_P) created by rs6000_legitimize_tls_address_aix: 5955 rtx modaddr = gen_rtx_SYMBOL_REF (Pmode, ggc_strdup (tlsname)); 5956 SYMBOL_REF_FLAGS (modaddr) |= SYMBOL_FLAG_LOCAL; and the ICE is on: 5830#ifdef HAVE_AS_TLS 5831 /* Do not associate thread-local symbols with the original 5832 constant pool symbol. */ 5833 if (TARGET_XCOFF 5834 SYMBOL_REF_TLS_MODEL (get_pool_constant (y)) = TLS_MODEL_REAL) 5835return orig_x; 5836#endif orig_x is (unspec:SI [ (symbol_ref:SI (*LCM..0) [flags 0x2]) (reg:SI 2 2) ] UNSPEC_TOCREL) Am I missing something here? Why does it assume that y is a CONSTANT_POOL_ADDRESS_P SYMBOL_REF? Alternatively, can you please attach auto-host.h, perhaps there is something I need to tweak further to reproduce.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #13 from Andrey Belevantsev abel at gcc dot gnu.org 2013-01-21 13:23:48 UTC --- (In reply to comment #12) I've tried to reproduce this with a cross compiler (without cross binutils) on x86_64-linux host, but it ICEs elsewhere: ../configure --target powerpc-ibm-aix5.3.1 --disable-bootstrap --enable-languages=c sed -i -e 's/^.*HAVE_AS_TLS.*$/#define HAVE_AS_TLS 1/' auto-host.h I've tried that too but with the powerpc-ibm-aix7.1.0.0 triplet from David's recent testresult mails, didn't even get as far as building generator programs from rs6000.md. I was also adding -mtune=power4 which looks similar to the reservations shown in David's dumps.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #14 from David Edelsohn dje at gcc dot gnu.org 2013-01-21 15:13:38 UTC --- Created attachment 29237 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29237 auto-host.h for AIX 7.1
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #15 from David Edelsohn dje at gcc dot gnu.org 2013-01-21 15:16:04 UTC --- libbacktrace only supports ELF file format and AIX does not use ELF, so libbacktrace will not work on AIX. Also, you patch called libbacktrace unilaterally, even without any verbose options and broke regular testing on AIX, which is not cool.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-21 15:25:00 UTC --- Using your auto-host.h (with the exception of HAVE_DECL_BASENAME - clearly host rather than target thing) with i686-linux - powerpc-ibm-aix7.1.0.0 cross I still get the same ICE I've talked about earlier in #c12 (for x86_64-linux - ppc-aix cross I need to also change SIZEOF_LONG and SIZEOF_VOID_P in auto-host.h to 8, but it also ICEs in the same spot).
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #17 from David Edelsohn dje at gcc dot gnu.org 2013-01-21 15:37:48 UTC --- AIX 5.3 does not support TLS, so there are pieces not implemented in config/rs6000/aix53.h. Jakub's configuration probably will not work. Also, GNU Binutils does not support AIX TLS or AIX 6.1/7.1, but you should not need Binutils to reproduce. rs6000_delegitimize_address() assumes the symbol is in the constant pool because all TOC symbols are in the constant pool. I thought that I associated the LCM symbol with the matching LC symbol, but that was in a different iteration of the patches. It probably needs a check for CONSTANT_POOL_ADDRESS_P().
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #18 from David Edelsohn dje at gcc dot gnu.org 2013-01-21 15:41:24 UTC --- Probably something like Index: rs6000.c === --- rs6000.c(revision 195319) +++ rs6000.c(working copy) @@ -5831,6 +5831,8 @@ /* Do not associate thread-local symbols with the original constant pool symbol. */ if (TARGET_XCOFF + GET_CODE (y) == SYMBOL_REF + CONSTANT_POOL_ADDRESS_P (y) SYMBOL_REF_TLS_MODEL (get_pool_constant (y)) = TLS_MODEL_REAL) return orig_x; #endif
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889
--- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-21
15:54:08 UTC ---
Indeed, with #c18 patch I can reproduce the ICE. Andrey, can you try that too?
On x86_64-linux, do for current trunk + #c18 patch applied:
mkdir obj
cd obj
../configure --target powerpc-ibm-aix7.1.0.0 --disable-bootstrap \
--enable-languages=c
make -j4
# The above command will fail, due to missing as/ld, but that is fine.
# You can even Ctrl-C it earlier, after gcc/auto-host.h is created
cd gcc
mv auto-host.h{,.bak}
wget http://gcc.gnu.org/bugzilla/attachment.cgi?id=29237 -O auto-host.h
sed -i -e 's/#define HAVE_DECL_BASENAME 0/#define HAVE_DECL_BASENAME 1/' \
-e 's/#define SIZEOF_LONG 4/#define SIZEOF_LONG 8/' \
-e 's/#define SIZEOF_VOID_P 4/#define SIZEOF_VOID_P 8/' auto-host.h
make -j4 cc1
cp -a ../../gcc/testsuite/gcc.dg/tree-prof/pr45354.c .
./cc1 -O -fschedule-insns -fselective-scheduling -fpic \
-fprofile-generate pr45354.c -maix32
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #20 from Andrey Belevantsev abel at gcc dot gnu.org 2013-01-21 17:31:57 UTC --- (In reply to comment #19) Indeed, with #c18 patch I can reproduce the ICE. Andrey, can you try that too? Sure, will do, I'll be out of office on Tuesday though. Thanks a lot for yours and David's help. The libbacktrace patch was just an attempt to get all the necessary information in the dump, only for this test. Sorry it didn't work out.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889
--- Comment #8 from Andrey Belevantsev abel at gcc dot gnu.org 2013-01-18
11:09:13 UTC ---
Created attachment 29202
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29202
more debug printing patch
From the log, the problem looks as follows. There is
insn 24, %3=[unspec[`*LCM..2',%2],
which is allowed to move past
insn 17, {%3=unspec[%3,%4] 25;clobber %0;clobber %4;clobber %5;clobber
%11;clobber %0;clobber lr;},
given that its target register will be renamed. After renaming, it shows as
insn 145, r192=[unspec[`*LCM..2',%2] 44]
but this insn is suddenly can not be moved through insn 17, thus the scheduler
aborts. The question is why insn 145 or insn 23, which looks like
r148=[unspec[`*LC..2',%2] 44] (same unspec code, etc), cannot be moved through
insn 17 while insn 24 can.
Attached is the patch that produces lots of debug output from the dependency
analysis. David, could you apply it on top of the previous one and run the
test case with -fsched-verbose=9 this time? (It uses libbacktrace, I'm not
sure whether AIX is fine with that, but even without this there will be a lot
more information.) Also, if you can clarify the above question on what is
different between insns 23/145 and 24 from the target point of view, it would
help a lot.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #9 from David Edelsohn dje at gcc dot gnu.org 2013-01-18 16:49:08 UTC --- Created attachment 29208 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29208 sched-verbose=9 dump output with debugging patch applied
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #10 from David Edelsohn dje at gcc dot gnu.org 2013-01-18 16:57:00 UTC --- Neither insn 24/145 nor insn 28 move through insn 17. The two UNSPEC 44 insn (LC..2,, LCM..2) are inputs to insn 17. The pseudos are moved into r3 and r4, which are the inputs to insn 17.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 Andrey Belevantsev abel at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |abel at gcc dot gnu.org |gnu.org | --- Comment #6 from Andrey Belevantsev abel at gcc dot gnu.org 2013-01-11 14:23:41 UTC --- Created attachment 29146 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29146 Restore debug printing David, could you apply the above patch and send to me the output of the compile command with the -fsched-verbose=6 option? The archive of the -fdump-rtl-all-all files will help as well. I couldn't get access to AIX so this is the only option for me now. (The patch is needed because the debug printing in sel-sched is currently broken, possibly after the sched-vis cleanups. I will apply it as obvious to trunk soon.)
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #7 from David Edelsohn dje at gcc dot gnu.org 2013-01-11 14:37:21 UTC --- Created attachment 29147 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29147 sched-verbose=6 dump output for failing testcase
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #5 from Andrey Belevantsev abel at gcc dot gnu.org 2013-01-09 14:26:22 UTC --- I've just got back from the holidays, I will take a look probably on Friday. David's analysis hints that the scheduler should treat the insn as unique (i.e. it is cannot be copied) but fails to do so.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 12:19:16 UTC --- Can't reproduce (with a cross). Is this when compiling 32-bit or 64-bit? What kind of CPU tuning by default?
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Target|powerpc*-*-*|powerpc-ibm-aix* --- Comment #3 from David Edelsohn dje at gcc dot gnu.org 2013-01-08 21:56:10 UTC --- Currently, I only can reproduce the ICE on 32 bit AIX (-maix32, the default).
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889
--- Comment #4 from David Edelsohn dje at gcc dot gnu.org 2013-01-09 02:52:51
UTC ---
Selective scheduling is failing for one of the new AIX TLS instructions when
encountered for that testcase. The necessary options are:
-O -fschedule-insns -fselective-scheduling -fpic -fprofile-generate
moveup_expr_cached() is called with expr-vinsn-insn_rtx of:
(insn 145 0 0 (set (reg:SI 192)
(mem/u/c:SI (unspec:SI [
(symbol_ref:SI (*LCM..2) [flags 0x2])
(reg:SI 2 2)
] UNSPEC_TOCREL) [0 S4 A8])) 346 {*movsi_internal1}
(nil))
and insn
(insn 17 16 20 2 (parallel [
(set (reg:SI 3 3)
(unspec:SI [
(reg:SI 3 3)
(reg:SI 4 4)
] UNSPEC_TLSTLS))
(clobber (reg:SI 0 0))
(clobber (reg:SI 4 4))
(clobber (reg:SI 5 5))
(clobber (reg:SI 11 11))
(clobber (reg:CC 68 0))
(clobber (reg:SI 65 lr))
]) /nasfarm/dje/src/src/gcc/testsuite/gcc.dg/tree-prof/pr50907.c:5 443
{tls_get_addr_internalsi}
(expr_list:REG_DEAD (reg:SI 4 4)
(expr_list:REG_UNUSED (reg:CC 68 0)
(expr_list:REG_UNUSED (reg:SI 65 lr)
(expr_list:REG_UNUSED (reg:SI 11 11)
(expr_list:REG_UNUSED (reg:SI 5 5)
(expr_list:REG_UNUSED (reg:SI 4 4)
(expr_list:REG_UNUSED (reg:SI 0 0)
(nil)
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Target||powerpc*-*-* Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Last reconfirmed||2013-01-06 Ever Confirmed|0 |1 Target Milestone|--- |4.8.0 --- Comment #1 from David Edelsohn dje at gcc dot gnu.org 2013-01-06 18:56:31 UTC --- Confirmed.
