[Bug middle-end/55889] New: [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling

[Bug middle-end/55889] New: [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889

             Bug #: 55889
           Summary: [4.8 Regression] ICE: in move_op_ascend, at
                    sel-sched.c:6153 with -fschedule-insns
                    -fselective-scheduling
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: dje@gcc.gnu.org


An ICE has appeared for target POWER when compiling
testsuite/gcc.dg/tree-prof/pr50907.c

$ /tmp/20130104/gcc/xgcc -B/tmp/20130104/gcc/
/nasfarm/dje/src/src/gcc/testsuite/gcc.dg/tree-prof/pr50907.c 
-fno-diagnostics-show-caret   -O -freorder-blocks-and-partition
-fschedule-insns -fselective-scheduling -fpic -pthread -fprofile-generate
-D_PROFILE_GENERATE  -lm   -o /tmp/20130104/gcc/testsuite/gcc/pr50907.x01

/nasfarm/dje/src/src/gcc/testsuite/gcc.dg/tree-prof/pr45354.c: In function
'test_ifelse2':
/nasfarm/dje/src/src/gcc/testsuite/gcc.dg/tree-prof/pr45354.c:23:1: internal
compiler error: in move_op_ascend, at sel-sched.c:6153

[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling

[dje at gcc dot gnu.org]

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.

[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling

[rguenth at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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

[dje at gcc dot gnu.org]

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

[dje at gcc dot gnu.org]

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

[abel at gcc dot gnu.org]

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

[abel at gcc dot gnu.org]

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

[dje at gcc dot gnu.org]

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

[abel at gcc dot gnu.org]

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

[dje at gcc dot gnu.org]

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

[dje at gcc dot gnu.org]

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

[abel at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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  0x0000000000cca50b in get_pool_constant (addr=0x7ffff1aa7ee0) at
../../gcc/varasm.c:3631
#1  0x0000000000ce285c in rs6000_delegitimize_address (orig_x=0x7ffff1a7aa20)
at ../../gcc/config/rs6000/rs6000.c:5834
#2  0x0000000000a04b0e in avoid_constant_pool_reference (x=0x7ffff1a7aa38) at
../../gcc/simplify-rtx.c:220
#3  0x0000000000e7c211 in equiv_constant (x=0x7ffff1a7aa38) at
../../gcc/cse.c:3797
#4  0x0000000000e7a811 in fold_rtx (x=0x7ffff1a7aa38, insn=0x7ffff1aa6750) at
../../gcc/cse.c:3122
#5  0x0000000000e7dd3c in cse_insn (insn=0x7ffff1aa6750) at
../../gcc/cse.c:4573
#6  0x0000000000e833f1 in cse_extended_basic_block (ebb_data=0x7fffffffdf40) at
../../gcc/cse.c:6405
#7  0x0000000000e83990 in cse_main (f=0x7ffff1a89200, nregs=190) at
../../gcc/cse.c:6583
#8  0x0000000000e8569c 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)
5835        return 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

[abel at gcc dot gnu.org]

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

[dje at gcc dot gnu.org]

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

[dje at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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

[dje at gcc dot gnu.org]

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

[dje at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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

[abel at gcc dot gnu.org]

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

[abel at gcc dot gnu.org]

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

[dje at gcc dot gnu.org]

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

[abel at gcc dot gnu.org]

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

[dje at gcc dot gnu.org]

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

[dje at gcc dot gnu.org]

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

[abel at gcc dot gnu.org]

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

[vmakarov at gcc dot gnu.org]

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

[abel at gcc dot gnu.org]

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

[vmakarov at redhat dot com]

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

[abel at gcc dot gnu.org]

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

[dje at gcc dot gnu.org]

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

[abel at gcc dot gnu.org]

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=gcc&view=rev&rev=196137
Log:
2012-02-19  Andrey Belevantsev  <abel@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

[abel at gcc dot gnu.org]

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.