UNSPEC_* handling in reg-stack.c
Uros Bizjak
uros@kss-loka.si
Wed Apr 28 10:40:00 GMT 2004
Jim Wilson 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.
I have replaced REG_DEAD handling with calls to abort(), and abort() was
never triggered.
>> 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.
UNSPEC_FPTAN is different, because it has two input parameters in top
two stack slots, but produces only one output. Top of stack is replaced
with output, and this register never dies. However, it is unclear to me,
why dying second register should be handled this way. In a couple of my
tests, second register is always at register nr.9 (alias FIRST_STACK_REG
+ 1), so even this test is redundant:
if (src2_note) {
printf("TEST: src2_note %i, %i\n", REGNO (XEXP (src2_note,
0)), FIRST_STACK_REG + 1);
replace_reg (&XEXP (src2_note, 0), FIRST_STACK_REG + 1);
}
this piece of code produces:
TEST: src2_note 9, 9
every time.
Uros.
More information about the Gcc
mailing list