UNSPEC_* handling in reg-stack.c

[Jim Wilson]

Uros Bizjak wrote:
> I have made some test-cases that exercise this part of code, but input 
> register was _never_ marked dead. This register is always replaced with 
> its output, so reload pass always assings output and input to the same 
> register. I would suggest changing this register handling to abort(), if 
> input register is marked REG_DEAD.

I don't know if anyone understands this code well enough to answer this 
definitively.  Probably the only way to be sure if to try it and see if 
it works.  And if it doesn't work, we document why.  Building glibc and 
running the math testsuite might be a good check.

Just looking at the code history, I see that the REG_DEAD note check has 
been there since the sin/cos support was first added to the i386.md file 
back in 1992.  I can't tell if there was a reason for it then or if 
maybe it has always been unnecessary.

Just looking at the i386.md, it does appear unnecessary, since we use a 
matching constraint, and thus the input and output operands should 
always be the same register.  You shouldn't get a REG_DEAD note in this 
case, you should only get a REG_UNUSED note for the output register if 
it is unused.  Unless maybe the REG_DEAD/REG_UNUSED semantics have 
changed since this code first went in.

> that never dies. The situation is different in UNSPEC_FPATAN & Co., 
> where second input register indeed dies, but it is unclear to me, why in 
> this case we need:
>        if (src1_note)  //redundant!!
>          replace_reg (&XEXP (src1_note, 0), FIRST_STACK_REG);
>        if (src2_note)
>          replace_reg (&XEXP (src2_note, 0), FIRST_STACK_REG + 1);

I am not sure what question you are asking here.  If there is a REG_DEAD 
note, then we must perform the same replacement we made in the insn. 
Otherwise, a later optimization pass may see the bad REG_DEAD note and 
perform an incorrect optimization.

If you are asking about the REG_DEAD note for src1, then I think the 
same answer applies as in the sin/cos case above.  It does appear that 
we should never have such a REG_DEAD note.

This feature was added more recently
   http://gcc.gnu.org/ml/gcc-patches/2003-02/msg00777.html
It might be possible to get comments from the author of the patch.  I 
would guess that the REG_DEAD handling was just the obvious extension of 
the same REG_DEAD handling that exists in the sin/cos case.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com