This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: UNSPEC_* handling in reg-stack.c
- From: Jim Wilson <wilson at specifixinc dot com>
- To: Uros Bizjak <uros at kss-loka dot si>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 26 Apr 2004 13:17:04 -0700
- Subject: Re: UNSPEC_* handling in reg-stack.c
- References: <408664E1.20309@kss-loka.si>
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