Re: [new-regalloc] Go into bootstrap land.

[Jan Hubicka <jh at suse dot cz>]

> > > >    (use (match_operand:HI 2 "memory_operand" "m,m"))
> > > >    (use (match_operand:HI 3 "memory_operand" "m,m"))
> > > >    (clobber (match_operand:DI 4 "memory_operand" "=m,m"))
> > > >    (clobber (match_scratch:DF 5 "=&1f,&1f"))]
> > >
> > > Hmm, on first sight this looks like a bug to me too, but I'm not at all
> > > sure.  I remember some issues.  Maybe writing the '&' already in the input
> > > constraint (where it would be more natural, if it's anyway clobbered)
> > > exposes some bugs, or simply doesn't work, so the clobber could be used,
> > > to actually fake a '&' for the input operands.  I think, that inputs _can_
> > > be earlyclobbers despite the contrary language in the docu.
> >
> > What exactly are you worrying about?  The fix_truncdi_nomemory works
> > by saving the operand to memory and then re-loading it back.  This is
> > because reload is unable to understand "general_operand" "m,m", that
> > can make thinks a lot cleaner.
> 
> So you suggest, that the allocator should understand that idiom?  I.e.
> accepting a general operand, but then constraining it to memory only?
> Would make sense to have something like this, yes.

This can definitly make your life easier when you write machine description
for such instructions (requiring one operand in memory).
This is not only i386 discovery, Sparc at least has same scheme for
fp<->integer unit converisons.

Currently we use two scheme - eighter we allocate the memory during RTL
generation loosing in case the operand will already prove to be memory
(then we do mem->mem copy first), or do this scheme of allocating memory
from register allocator still loosing, as regalloc and reload often loads
the operand from memory for us first, resulting in unneeded mem->mem copy
again.
> 
> > In case you are speaking about "=&1f", in old register allocator this
> 
> Yes, this is, what was worrying us.  Interpreting "=&1f" strictly per
> documentation has the meaning of "make this operand the same as operand 1,
> and make it clobber early."  From which follows, that operand 1 is
> earlyclobbered.
> 
> > worked as "take register different from all inputs, or equivalent to
> > input operand 1 if it is unique"
> 
> Which is a different meaning from the documented one (Normally a "1" in
> the constraints does not permit _not_ to use the same as op1).  Is this
> really the special meaning?  Or just something which reload happens to do
> by accident?

It is used on several places in the kernel.  AFAIK it is the current way
to write such kind of patterns, saying - if the operand is already somewhere,
good, I don't need earlyclobbered temporary, but otherwise I will.
This happends from time to time.

Perhaps rewriting it to "=&X,f" (and splitting the alternatives) will work as
well, but we seems to do it this way.

I would suggest to keep the meaning to avoid obstakles, but we may also kill
it and add error message when earlyclobber is used together with matching
operand in the asm statement.

Honza
> 
> 
> Ciao,
> Michael.