Re: IRA_COVER_CLASSES for m32c

[Vladimir Makarov <vmakarov at redhat dot com>]

DJ Delorie wrote:
> Opening this up to the gcc public, since I appear to be unable to get
> this to work right.
>
>
> Still no luck defining a working IRA_COVER_CLASSES for m32c.  My
> latest attempt:
>
> #define IRA_COVER_CLASSES \
> { \
>   HC_REGS, MEM_REGS, LIM_REG_CLASSES	\
> }
>
> (effectively GENERAL_REGS (which I also tried), but MEM_REGS regs are
> implemented as memory locations, so I had tried without them) results
> in this build failure in newlib:
>
> m32c-elf-gcc -B/greed/dj/m32c/newlib/m32c-elf/m32c-elf/m32cm/newlib/ -isystem /greed/dj/m32c/newlib/m32c-elf/m32c-elf/m32cm/newlib/targ-include -isystem /greed/dj/m32c/newlib/src/newlib/libc/include -B/greed/dj/m32c/newlib/m32c-elf/m32c-elf/m32cm/libgloss/m32c -L/greed/dj/m32c/newlib/m32c-elf/m32c-elf/m32cm/libgloss/libnosys -L/greed/dj/m32c/newlib/src/libgloss/m32c  -mcpu=m32cm -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"1.16.0\" -DPACKAGE_STRING=\"newlib\ 1.16.0\" -DPACKAGE_BUGREPORT=\"\" -I. -I../../../../../../src/newlib/libc/stdlib -Os -DPREFER_SIZE_OVER_SPEED -DABORT_PROVIDED -DSMALL_MEMORY -DMISSING_SYSCALL_NAMES -fno-builtin      -g -O2    -mcpu=m32cm -DINTERNAL_NEWLIB -DDEFINE_MALLOC -c ../../../../../../src/newlib/libc/stdlib/mallocr.c -o lib_a-mallocr.o
> ../../../../../../src/newlib/libc/stdlib/mallocr.c: In function '_malloc_r':
> ../../../../../../src/newlib/libc/stdlib/mallocr.c:2588: error: unable to find a register to spill in class 'HL_REGS'
> ../../../../../../src/newlib/libc/stdlib/mallocr.c:2588: error: this is the insn:
> (insn 661 660 662 101 ../../../../../../src/newlib/libc/stdlib/mallocr.c:2194 (set (reg:HI 0 r0 [262])
>         (and:HI (subreg:HI (reg:PSI 5 a1 [258]) 0)
>             (const_int 127 [0x7f]))) 26 {andhi3_24} (expr_list:REG_DEAD (reg:PSI 5 a1 [258])
>         (nil)))
> ../../../../../../src/newlib/libc/stdlib/mallocr.c:2588: internal compiler error: in spill_failure, at reload1.c:2093
>
>
> As I've said before, m32c is probably a "worst case" scenario for gcc
> as it has not one, not two, not even three, but FOUR different types
> of registers (8/16 bit general, 16 bit only general, 24 bit address
> registers, and control (incl $fp) registers), and only a small number
> (2) of each.
>
> I'm beginning to suspect that anyone doing ANYTHING with register
> allocation or reload should include m32c in their testing, as it seems
> to have broken every time those got changed.
>
> Vlad, could you try your hand at this?  Please? :-)
>
>   
Sure, DJ.  I'll look at this but unfortunately I can do it on next week 
because I am busy with numerous other IRA bugs.  As I wrote m32c is 
pretty nasty case and may be will need even insn description changes.

If we find that RA is not possible for m32c or other weird targets 
(Joerne wrote about one them) with non-intersected register classes 
(cover classes), I could implement priority coloring for intersected 
register classes.  I think it will be about 100 lines of additional 
code.  But I'd rather avoid this scenario.