Re: Help-The possible places where insn is splitted in greg pass

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Qifei Fan wrote:

> > But insn#479 is not recognized by recog() in insn-recog.c and the
> > compilation failed. (recog only recognizes RTL defined in md, right?)
> > Here the backtrace is
> > reload--->cleanup_subreg_operands--->extract_insn_cached--->extract_insn-=
> -->recog_memoized--->recog.
> > There is no machine instruction(r3=3Dr1*4+r2) match the pattern of
> > insn#479. Though there is pattern r3=3Dmem(r1*4+r2).
> > I don=92t quite understand the generation of reload information.

There's two issues here.  The first issue is that reload makes the
fundamental assumption that everything that is a valid address, can
be loaded into a register as well, if necessary.  On many platforms
this is true, either because there is some sort of "load address"
instruction, or because the form of valid addresses matches standard
arithmetic instruction patterns.  Reload will simply emit a naked
"set" of some register to the address -- if the back-end doesn't
support that, you'll get the failure you saw.

If this doesn't work on your particular platform, you could either
try to set things up so that reload never thinks it needs to reload
an address (but this may be difficult to achieve).  The safe option
would be to tell reload how to achieve computing an address by
providing a "secondary reload" pattern.  See e.g. s390_secondary_reload
(in config/s390/s390.c) and the associated "reload<mode>_plus" pattern.

The second issue is as you notice here:

> Actually the second reload is not needed if there is already the first relo=
> ad.
> If (plus:SI (reg/f:SI 16 SP)  (const_int 96 [0x60]) is replaced by
> (reg:SI 12 a12), then (plus:SI (mult:SI (reg:SI 9 a9 [204])
> (const_int 4 [0x4])) (reg:SI 12 a12) ) is a valid memory address.
> But in function find_reloads, I can=92t find the related code that
> deciding whether the second reload should be generated by regarding
> the previous reload.  The function is too complex. :-(

The first reload, loading sp + 96 into a register, is generated from
within find_reloads_address.  After this is done, it is assumed that
the address is now valid.

However, something else later in find_reloads apparently assumes there
is still some problem with the operand, and decides to reload the
whole address.  It is hard to say exactly what the problem is, without
seeing the insn constraints, but the most likely cause seems to be that 
this instruction pattern does not have a general "m" constraint, but
a more restricted memory constraint.

If this is the case, the back-end procedure called to verify the 
constraint probably rejects it.  This runs into another fundamental
assumption reload makes: it assumes such procedures take other
actions done by reload into account implicitly.  This means the
constraint checker ought to *accept* addresses of the form
   reg*const + (sp + const)
because it ought to know that reload will already load the (sp + const)
into a register anyway.

If this is *not* the case, please send me the instruction pattern
and constraints for the insn pattern that matched insn 320 before
reload so I can investigate in more detail.

(Please note that I'm currently travelling with restricted access
to email, so it might be a couple of days before I'm able to reply;
sorry ...)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com