[Bug middle-end/32267] New: [4.0/4.1 Regression] can't find a register in class 'GENERAL_REGS' while reloading 'asm'

["rob1weld at aol dot com" <gcc-bugzilla at gcc dot gnu dot org>]

+++ This bug was initially created as a clone of Bug #21291 +++
works with -O0, fails with -O[123]. 
gcc-4.0.0 + patches for pr20973,21173.

I could not reopen http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21291 so I
thought I'd try clicking on clone this bug since it has re-emerged in 4.2.0 and
4.3.0. The summary is what the origonal was and close enough for me.


This bug (which _I_ call GENERAL_REGS ) occurs on 4.2.0 (or greater) when
compiling ffmeg in the files:

h264.c
cabac.h: In function `get_cabac_noinline':
cabac.h:513: error: can't find a register in class `GENERAL_REGS' while
reloading `asm'
h264.c: In function `decode_cabac_residual':
h264.c:6143: warning: passing arg 4 of `decode_significance_8x8_x86' discards
qualifiers from pointer target type
cabac.h:729: error: can't find a register in class `GENERAL_REGS' while
reloading `asm'
cabac.h:680: error: can't find a register in class `GENERAL_REGS' while
reloading `asm'


and here:

i386/h264dsp_mmx.c: In function `h264_h_loop_filter_luma_mmx2':
i386/dsputil_mmx.c:636: error: can't find a register in class `GENERAL_REGS'
while reloading `asm'
i386/dsputil_mmx.c:636: error: can't find a register in class `GENERAL_REGS'
while reloading `asm'
i386/dsputil_mmx.c:636: error: can't find a register in class `GENERAL_REGS'
while reloading `asm'
i386/dsputil_mmx.c:636: error: can't find a register in class `GENERAL_REGS'
while reloading `asm'
i386/dsputil_mmx.c:636: error: can't find a register in class `GENERAL_REGS'
while reloading `asm'
i386/dsputil_mmx.c:636: error: can't find a register in class `GENERAL_REGS'
while reloading `asm'
make[1]: *** [i386/dsputil_mmx.o] Error 1


The "fix" for ffmpeg is to add "-fomit-frame-pointer" or change the "-O?" in
the Makefile for these particular files only. Ffmpeg build OK with this fix.


The error message about `GENERAL_REGS' comes from file gcc\reload1.c , in
function spill_failure(). The error message about "impossible constraints"
comes from the same file in function reload(). 

The reload() function has a note which reads as follows:
" /* Clean up invalid ASMs so that they don't confuse later passes. See PR
21299. */ "


This error also occurs in gcc version 4.3.0 20070607 when the testsuite is used
- This is why I am writing this bug report. The testsuite use "-O" so I
compiled the file with each type of optimization:


gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/ pr21291.c -O0 -S -o pr21291-O0.s

gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/ pr21291.c -O1 -S -o pr21291-O1.s
pr21291.c: In function 'bng_ia32_mult_sub_digit':
pr21291.c:23: error: can't find a register in class 'GENERAL_REGS' while
reloading 'asm'
pr21291.c:23: error: 'asm' operand has impossible constraints

gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/ pr21291.c -O2 -S -o pr21291-O2.s

gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/ pr21291.c -O3 -S -o pr21291-O3.s

gcc/xgcc -B/opt/gcc-4_3-build-2/gcc/ pr21291.c -Os -S -o pr21291-Os.s


Only "-O1" had trouble. We need to alter the test code to use even MORE
registers and alter the expect scripts to check each type of optimization along
with other parameters that will use up MORE and LESS registers to _fully_
"exercise" this test.

I did "diff -Naur" of the reulting ".s" files and found that of the ones that
were created many were not particularly optimized in any event!


The "diff -Naur pr21291-O0.s pr21291-O2.s" showed that "-O0" was quite lengthy
compared to "-O2" - not much of a surprise. The "-O2" and "-O3" were identical. 

The "diff -Naur pr21291-O2.s pr21291-Os.s" is what was interesting. The "-Os"
code was the smallest and fastest it used "push/pop" instead of a series of
"movl"s.


If the compiler could detect that it has ran out of registers and make new
assignments either get pushed to stack _OR_ stored to a static local memory
location then it would have as many 'registers' (real or fake) as it needed.

If it could discover that the chosen optimization caused the registers to run
out and re-try using a different optimization level and then re-feed the
optimized code back into the routine at the chosen optimization level then it
may be able to dump un-needed registers from the list - this would be more
expensive.

Whatever the compiler chooses to do it must NOT fail by running out of
registers - it should make best efforts to discover which variables would be
best _IF_ they went into registers (as the person who wrote the code requested)
and failing to be able to do what the programmer requested to simply use memory
space for "faking" the remaining needed registers.

It is not hard to do - unless you would have us beleive that each variable in a
program must have it's own register for the whole life of the program, that is
not the case.


-- 
           Summary: [4.0/4.1 Regression] can't find a register in class
                    'GENERAL_REGS' while reloading 'asm'
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rob1weld at aol dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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