Re: state of 3.2.1-pre: how far from release?

[Michael Matz <matz at suse dot de>]

Hi,

On Wed, 6 Nov 2002, David Edelsohn wrote:

> 	reg 31 is the frame pointer, before elimination, so the first
> force_reg moved a frame pointer offset address into a pseudo.

Ok, nothing bad until now.

> eliminate_regs_in_insn() first converts that instruction to:

Does the insn before eliminate_regs_in_insn() only contains refs to (reg
929)?  And is reg_renumber[929] smaller zero, but reg_equiv_constant[929]
is non-zero (and points to the rtl (plus:SI (reg r1) (const_int 520))?  If
the answer to all these is yes, I think I know what happens, but not
exactly why.

The loop over all operands in eliminate_regs_in_insn() calls
eliminate_regs() for each operand (which is eliminable according to the
insn_data[] info), and places the results into substed_operand[].  If
eliminable_regs() is called on a pseudo reg (i.e. one which didn't get a
hard reg), but which has an equivalent constant (the (plus r31 520) in
this case, because of the REG_EQUIV note), then it returns that constant
(possibly recusively eliminating other regs).

Now the content of substed_operand[] is placed back into the places of the
old operands, but according to the recog_data information.  Because you
create that four-vector directly, and the matching insn pattern simply has
a (match_parallel) there, recog_data has no information about the other
operands, neither as normal operands, nor as (match_dup) like operands.
That's why the new rtl expression only is placed into the first operand
(for which there is a match_operand in the .md files).

As reload is working more or less only on operands as they are known by
recog(), I anyway wonder how such patterns are going to work, although I
might miss something.  Bug AFAIK reload never sees those additional
operands, and can't fix them up.  It's not reload itself which ICEs, but a
later pass, which really looks at the RTL, instead of just operands.

Just to confirm I would be interested which value recog_data.n_operands
and .n_dups have for this insn.

If it's the above reason, I'm not sure we want to fix this.  And if we do,
then probably not in reload, but in recog, in the sense that it fills
recog_data correctly with the additional operands.

I think the following way would work:

for a (match_parallel N PREDICATE [SUBPAT ...]) we additionally require
that not only the first corresponding elements of the parallel match the
SUBPAT, but _all_ of them (I'm looking at 3.2 docu, so that might be
outdated, or already required).  For match_operands in SUBPAT we would do
the obvious thing.  Given for instance this pattern:
(match_parallel 0 "bla"
 [(set (match_operand:SI 1 "blubb" "=r")
       (match_operand:SI 2 "blabla" "rm"))]

when matching this insn:
(parallel [
 (set (reg 1) (reg 2))
 (set (reg 3) (reg 4)) ] )

We would have operand 1 and 2 be (reg 1) resp. (reg 2), obviously, but
additionally we allocate more operands if needed (after setting all
explicitely mentioned match_operands), which would lead to operand 3 and 4
be (reg 3) and (reg 4).  I.e. for those things the operand number N in the
(match_operand) would be just a placeholder to be filled out by max
operand number till now plus N (or maybe also consecutively assigned,
but in relative order of the SUBPAT).

I'm not sure how difficult for recog that would be, and how many parts of
the compiler would be surprised to see different numbers of operands for
recog_data of the same insn code.  But if we would do that reload() would
magically start to work in this and similar situations.

That of course is nothing for 3.2, and probably not even 3.3.

> is reloaded into a reg because the instruction does not accept an
> offsettable address.  Only the address in the first operand of the
> parallel is substituted again.

Yep, the same reason as above.  reload() simply doesn't see those operands
at all.


Ciao,
Michael.