This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Performance regression
- From: David Edelsohn <dje at watson dot ibm dot com>
- To: Dale Johannesen <dalej at apple dot com>
- Cc: Richard Henderson <rth at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Mon, 30 Sep 2002 14:42:01 -0400
- Subject: Re: Performance regression
>>>>> Dale Johannesen writes:
Dale> The obvious difference is the lack
Dale> of the REG_EQUAL note. Is this right?
I have concurrently tracked the bug back to the same REG_EQUAL
note, although I do not know whether the NOTE is wrong or GCC is handling
the NOTE incorrectly or missing another NOTE.
In the buggy case, cse_insn analyzes the next unrolled load:
(insn 195 194 196 0 30038e00 (set (reg:SI 156)
(zero_extend:SI (reg/v:HI 171))) -1 (nil)
(expr_list:REG_EQUAL (zero_extend:SI (mem:HI (plus:SI (reg:SI 133)
(symbol_ref:SI ("bndpsd"))) [4 S2 A16]))
(nil)))
and examines the REG_EQUAL note to find a SRC_EQV. It finds the first
load, so it substitutes (reg:SI 156):
(insn 195 194 196 0 30038e00 (set (reg:SI 156)
(reg:SI 156)) 291 {*movsi_internal1} (nil)
(expr_list:REG_EQUAL (zero_extend:SI (mem:HI (plus:SI (reg:SI 133)
(symbol_ref:SI ("bndpsd"))) [4 S2 A16]))
(nil)))
ignoring the intervening SET of (reg:HI 171).
The three possibilities are:
1) Load of (reg:SI 156) from (reg:HI 171) should not have a REG_EQUAL
note.
2) Store to (reg:HI 171) also *should* have a REG_EQUAL note.
3) cse_insn should not validate the change due to the intervening store to
(reg:HI 171).
The semantics of REG_EQUAL are that the register value is
equivalent to the NOTE value at runtime at that instant, but not
necessarily elsewhere in the function, so I think the NOTE is okay, but
the substitution is not checking validity correctly. I do not know if
adding a REG_EQUAL to the store should be necessary.
David