Bug 156566 - unable to find a register to spill in class 'GENERAL_REGS'
unable to find a register to spill in class 'GENERAL_REGS'
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-01 17:28 EDT by Enrico Scholz
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-02 07:25:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Enrico Scholz 2005-05-01 17:28:39 EDT
Description of problem:

The following code fails to compile with gcc-4:

----
register void *env asm("ebp");
register unsigned int T0 asm("ebx");
register unsigned int T1 asm("esi");
register unsigned int T2 asm("edi");

typedef union {
    unsigned short      _w[4];
} MMXReg;

void op_pshufw_mmx (void)
{
    MMXReg r, *d=0, *s;
    int order;
    s = (MMXReg *)((char *)env);
    r._w[0] = s->_w[order>>1];
    r._w[1] = s->_w[order];
    *d = r;
}
----

| $ gcc -O1 x3.c
| x3.c: In function 'op_pshufw_mmx':
| x3.c:18: error: unable to find a register to spill in class 'GENERAL_REGS'
| x3.c:18: error: this is the insn:
| (insn 14 13 17 0 (set (strict_low_part (subreg:HI (reg/v:DI 60 [ r ]) 0))
|         (mem/s/j:HI (plus:SI (mult:SI (reg:SI 61)
|                     (const_int 2 [0x2]))
|                 (reg/v/f:SI 59 [ s ])) [0 <variable>._w S2 A16])) 41 {*movstricthi_1} (insn_list:REG_DEP_TRUE 33 (insn_list:REG_DEP_TRUE 11 (insn_list:REG_DEP_TRUE 13 (nil))))
|     (expr_list:REG_DEAD (reg:SI 61)
|         (nil)))
| x3.c:18: confused by earlier errors, bailing out


Omitting the '-O1' or compiling it with gcc32 makes it succeed.



Version-Release number of selected component (if applicable):

gcc-4.0.0-0.40


How reproducible:

100%
Comment 1 Warren Togami 2005-05-01 17:53:38 EDT
What software is this from?  Anvil saw something similar yesterday that failed
with gcc-4.0.0-1 but worked with gcc-4.0.0-2.
Comment 2 Jakub Jelinek 2005-05-02 07:25:28 EDT
Limiting GCC to 3 general purpose registers on i386 is insane, it never worked
reliably and never will.  I have verified that this ICEs on
all of 3.2.3, 3.4.3 and 4.0.  One, worst case maybe 2 global reg variables
are bearable, but certainly not 4 on an already register starved architecture.

The particular thing is that because the structure is 8 bytes, GCC assigns
a DImode pseudo to the r variable and DImode needs a pair of consecutive
registers.  There is only one available because the global reg vars,
%eax/%edx and one of the instructions also needs a register for order
(index into the array) and base (s->_w).

For 4.1 DImode on 32-bit arches perhaps might be split up earlier, as tree-SSA
optimizations will see the 64-bit values, so perhaps this particular case
would be cured.  Still, there are lots of other places where relying on code
working with just 3 general regs is not going to work.

Note You need to log in before you can comment on or make changes to this bug.