update_flow_info error for rs6000-ibm-aix4.1.5 configuration

[David S. Miller]

   Date: Sat, 17 Oct 1998 02:19:31 -0600
   From: Jeffrey A Law <law@cygnus.com>

     In message < 9810162133.AA56656@marc.watson.ibm.com >you write:
     > >>>>> Jeffrey A Law writes:
     > 
     > Jeff> In message < 9810161913.AA41810@kitch9.watson.ibm.com >you write:
     > >> FYI, I am receiving an internal compiler error in
     > >> haifa-sched.c:update_flow_info() from the current CVS sources for
     > >> rs6000-ibm-aix4.1.5 configuration.
     > >> 
     > >> haifa-sched.c:8085: Internal compiler error in function update_flow_info
     > Jeff> During a bootstrap or with a specific testcase?  Do you have a .i fil
     > e?
     > 
     > 	Sorry, yes, during bootstrap, stage1 compiler, compiling libgcc.a:
   Thanks.   Unfortunately, it didn't fail for me.  The most common cause of this
   would either be an uninitialized memory read, variable or something along those
   lines or a bug in whatever compiler you used to build the stage1 compiler.

   I've checked in a few fixes since yesterday which may or may not address
   this problem (I tried a build with the sources just after the big flow checkin).

A short note, I get the same for execute/compile-1.c in gcc.c-torture
on sparc for -O2

You may be able to reproduce it more easily using that.

I think I see what is going on, here are some debugging dumps at the
time of the crash.  The note list is:

(expr_list:REG_DEAD (reg:SI 26 %i2)
    (expr_list:REG_DEAD (reg:SI 27 %i3)
        (expr_list:REG_DEAD (reg/v:DF 16 %l0)
            (expr_list:REG_UNUSED (reg:SI 26 %i2)
                (expr_list:REG_UNUSED (reg:SI 27 %i3)
                    (nil))))))

The insn in the list from first to last which sets %i2 is:

(insn 68 65 41 (set (reg:DF 26 %i2)
        (mem:DF (plus:SI (reg:SI 30 %fp)
                (const_int -8)) 0)) 160 {*movdf_insn_sp32} (nil)
    (nil))

and then there are a bunch of uses:

(insn 41 68 49 (use (reg/i:DC 24 %i0)) -1 (insn_list:REG_DEP_ANTI 3 (insn_list:REG_DEP_ANTI 7 (insn_list:REG_DEP_ANTI 14 (insn_list:REG_DEP_ANTI 16 (insn_list:REG_DEP_ANTI 18 (insn_list:REG_DEP_ANTI 21 (insn_list:REG_DEP_ANTI 23 (insn_list:REG_DEP_ANTI 26 (insn_list:REG_DEP_ANTI 29 (insn_list:REG_DEP_ANTI 31 (insn_list:REG_DEP_ANTI 36 (insn_list:REG_DEP_ANTI 38 (insn_list 40 (nil))))))))))))))
    (expr_list:REG_DEAD (reg/i:DC 24 %i0)
        (nil)))

as float complexes value are returned in integer registers on Sparc.
I believe the problem is that the mode has changed.

This is a result of some of the splits on sparc.md, and I now realize
how illegal this is.  I tried very hard to make sure such mode changes
only happened after reload, and the scheduler used to allow these just
fine.

I believe rs6000 is suffering from the same problem here.

Just to explain, often it is easier for me to change the modes on
floats to split up operations on multi-register quantities.  One
example that comes to mind is where a floating constant is being
loaded to a SFmode register, which happens to be assigned an integer
hard regiser (this is common for parameter passing on 32-bit sparc).
If I pun the mode to SImode, I can even handle all the constant
loading cases which require 2 instructions.  If I left it at SFmode
I'd have to do a lot of ugly stuff and still have the 1 to 1 RTL insn
to sparc insn schedulable mapping.

Later,
David S. Miller
davem@dm.cobaltmicro.com