Re: Incomplete instatitiation of virtual registers

[Martin Koegler <mkoegler at auto dot tuwien dot ac dot at>]

On Tue, May 03, 2005 at 05:44:47PM -0700, James E Wilson wrote:
> Martin Koegler wrote:
> >I notice, that your last change in function.c forgets virtual
> >registers in the RTL in some conditions. In older version (the last I used 
> >was 20050412),
> >this has not happend.
> 
> Patches should go to gcc-patches instead of the gcc list.
> 
> If you want us to continue accepting patches from you, then you need to 
> fill out a copyright assignment form.
> 
> Recursively calling instantiate_virtual_regs_in_insn does not look 
> right.  We need a better explanation of what is going wrong here.  Since 
> we don't have a copy of your port, you will have to explain in detail 
> what happens as virtual register instantiation is happening, in order to 
> explain how this occurs.  Normally, we would ask for a testcase, but 
> that won't work in this case.

In that case, I didn't want to get this patch in GCC. In only wanted to
inform, that the code forgets some registers and that a rerun of 
instantiate_virtual_regs_in_insn solves the problem. I don't know, 
if a bug report is ok in such a case (as I have not reproduced it in
a offical version), so I send a mail to Richard Henderson, who did
the last change with CC to the GCC list.

> It is also possible that this is a bug in your port, if you are 
> accidentally emitting the virtual register yourself somehow during or 
> after virtual register instantiation.

I discovered the problem, while running a regression test, after
I have updated the GCC core. Many compilations failed in
refers_to_regno_for_reload_p. It turned out, that the instantiations
forget some registers. Adding the two lines of code, it worked again.

For that instruction, instantiate_virtual_regs_in_insn
enters if(set), then if (GET_CODE (SET_SRC (set)) == PLUS 
is entered, where if (safe_insn_predicate (insn_code, 1, new) is entered.
It then jumps to verify, without changing the destination, because it is
MEM expression. After the verify label, no more change of the destination will happen.

As far as I have seen, instantiate_virtual_regs_in_insn is called
for each instruction only once.

Richard Henderson wrote:
> I'd like to see the define_insn for {addhi3}.  I'm a bit confused as
> to how I could have missed iterating over what appears like it ought
> to be match_operand 0.

(define_insn_and_split "addhi3"
[(set (match_operand:HI 0 "regmemptne_operand" "=&rATQ,&rRBU,&rRBU")
  (plus:HI
    (match_operand:HI 1 "regmemimmpt_operand" "rATQi,0,rATQI")
    (match_operand:HI 2 "regmemimmst_operand" "rRBUi,rRBUi,0")
))]
....)


I put the patches and new files for the m68hc05 Port again CVS Versions
of GCC, Binutils, GDB and newlib of 20050501 at:
http://www.auto.tuwien.ac.at/~mkoegler/m68hc05/m68hc05.tar.gz (120k)

It is a development shapshot and requires still a lot of work.
I have some not yet published documenations about the internals of the GCC port (predicates, constraints,...),
if it is needed.

Patching and compiling everything, except GCC, is described at
http://www.auto.tuwien.ac.at/~mkoegler/index.php/bcus and nested pages.

For compiling m68hc05-gcc, a patch (gcc.patch) plus the files in gcc/config/m68hc05 are needed.
(In addition to config.sub.patch for adding the processor)

mfg Martin Kögler
e9925248@stud4.tuwien.ac.at