Re: GCC 3.1.1 Status

[Jan Hubicka <jh at suse dot cz>]

> 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.

Yes, unless we combine something together.
> 
> > 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.

I remeber that when I was fixing the SUBREG_BYTE issues, there has been
tons of places in the compiler, where the subregs were combined together
for some reason.  I redirected them all to simplify_subreg.  There are
18 simplify_subreg calls and 19 simplify_gen_subreg calls, but perhaps
none of these attempts to throw in such combination except the one in
combine, I really don't know.
> 
> > > 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.

I see.  I've missed the fact that the register is QImode when I was
looking into this.
> 
> 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?

You can get it by including  mmintin.h in x86-64 cross, I will dig out
the error message, but it basically complains about to register to spill
in the MMX class, so it looks like equivalent problem.  On the other
hand I don't see what mode can be prohibited in MMX.

Honza
> 
> 
> Bernd