Re: GCC 3.1.1 Status

[Bernd Schmidt <bernds at redhat dot com>]

On Wed, 19 Jun 2002, Jan Hubicka wrote:

> > > The register costs are high for fp<->integer conversions and somehow the
> > > cheapest comes out MMX_CLASS. Register allocation decides to put
> > > register there and later we die.
> > > 
> > > I am not sure how to fix that properly...  Hope that helps :)
> > 
> > Well, I'm relatively sure how to fix it properly - disallow paradoxical
> > FLOAT_MODE subregs like the one we have up there.  This kind of rtl seems
> 
> This makes sense.  I tought those gets constructed in union/structure
> handling so they are dificult to disable?  This may be the case of
> nonparadoxical subregs only.

I think for structs we always want to extract a field that's smaller than the
entire object, so the subregs we get out of this should be non-paradoxical.

> But won't same problems show up for
> combination for integer/float as well (ie non-paradoxical).

Quite possibly.

> Other problem may be that a lot of parts of compilers gets surprised
> when subregs fails to combine.

How so?  The only thing that should happen is that combine won't perform
that particular combination and everything is left as it was before.  I
don't think anything outside combine will try to generate a subreg like
this one.

> > a bit dodgy at best.  But before I commit the patch I have I'll need to
> > figure out why exactly reload blows up; that may or may not be a bug.
> 
> This may solve my problem in x86-64 mode as well, where reload
> intreg->mmx is generated any time __m64 is passed via function argument
> (as it is long long at the moment). I am getting similar errors in such
> cases.

Hmm.  The problem here is the following reload:

Reload 0: reload_in (SF) = (reg:SF 8 st(0) [91])
        reload_out (QI) = (reg:QI 90)
        FLOAT_REGS, RELOAD_OTHER (opnum = 0)
        reload_in_reg: (reg:SF 8 st(0) [91])
        reload_out_reg: (reg:QI 90)

and there isn't a FLOAT_REG that will hold a QImode value, so we fail the
test in set_reload_reg for each attempted FLOAT_REG.  Basically, since
reg 90 didn't get a hard, we'd be trying to move a byte from a floating
point register to a memory location, and that is obviously not going to
work.  So, we certainly should never have made a reload like this one.

All of this might have worked better if push_reload hadn't decided to strip
the subreg (it gets passed "(subreg:SF (reg:QI 90))" for OUT).  But then,
I certainly don't fully understand the logic behind the 60 line if conditions
that deal with subregs, so it's hard to decide what to do about it.

Can you show me an example of what happens in the x86-64 case?


Bernd