Bernd Schmidt wrote:
Mark Shinwell wrote:
Do you think it should be the case that, at the point below, _any_ reload
with reg_rtx corresponding to a hard register should have the relevant
bit set in reload_spill_index?
I think so. I'm attaching a patch below. It appears to have no effect
on
Mark Shinwell wrote:
Bernd Schmidt wrote:
Mark Shinwell wrote:
Do you think it should be the case that, at the point below, _any_
reload
with reg_rtx corresponding to a hard register should have the relevant
bit set in reload_spill_index?
I think so. I'm attaching a patch below. It
Mark Mitchell wrote:
Bernd Schmidt wrote:
Mark Shinwell wrote:
Do you think it should be the case that, at the point below, _any_ reload
with reg_rtx corresponding to a hard register should have the relevant
bit set in reload_spill_index?
I think so. I'm attaching a patch below. It appears
Bernd Schmidt wrote:
Mark Shinwell wrote:
Do you think it should be the case that, at the point below, _any_ reload
with reg_rtx corresponding to a hard register should have the relevant
bit set in reload_spill_index?
I think so. I'm attaching a patch below. It appears to have no effect
On Mon, Jun 11, 2007 at 09:22:24AM +0100, Mark Shinwell wrote:
+ if (rld[r].when_needed == RELOAD_FOR_INPUT
+ rld[r].reg_rtx
+ REGNO (rld[r].reg_rtx) FIRST_PSEUDO_REGISTER)
+ {
$ grep -F -e HARD_REGISTER gcc/rtl.h
#define HARD_REGISTER_P(REG)
I've run into a case where reload clobbers a register which it had
decided to use for reload inheritance. Reload is given this:
(insn 623 430 431 35 ../../.././gcc/dp-bit.c:734 (set (reg:HI 162 [+6 ])
(mem/c/i:HI (plus:HI (reg/f:HI 10 bp)
(const_int -2 [0xfffe])) [0
Mark Shinwell wrote:
As you say, one unusual thing about this situation must be the fact
that the reload register is getting chosen by the code in
push_reload heralded by If this is an input reload and the operand
contains a register that dies in this insn and is used nowhere else,
see if it
Bernd Schmidt wrote:
My gut feeling is that this example will work as a consequence.
... note that I inserted some other insn which could conceivably use
R9 as an input reload, as the hard reg is dead. Where would we
invalidate previous information about R9? I assume it would be the loop
at
Mark Shinwell wrote:
This code is guarded by
/* I is nonneg if this reload used a register.
If rld[r].reg_rtx is 0, this is an optional reload
that we opted to ignore. */
if (i = 0 rld[r].reg_rtx != 0)
and in this [my original] case, i is negative (see my
Bernd Schmidt wrote:
It appears that spill_reg_index is only set up for registers that go
through the choose_reload_regs process, not for the ones selected during
find_reloads. That's probably a bad thing, as a reg_rtx chosen in
find_reloads could be used as a spill reg in a previous insn (as
Mark Shinwell wrote:
and the code following in emit_reload_insns? Perhaps if spill_reg_index
took account of registers selected during find_reloads then this could
be simplified too.
So what do you think is the best approach to fix all of this? :-)
Sounds like you gave the answer yourself
Bernd Schmidt wrote:
Mark Shinwell wrote:
and the code following in emit_reload_insns? Perhaps if spill_reg_index
took account of registers selected during find_reloads then this could
be simplified too.
So what do you think is the best approach to fix all of this? :-)
Sounds like you gave
Bernd Schmidt wrote:
insn 5301: (set (reg/f:SI 4082) (reg/f:SI 3275))
insn 5291 (set (reg:DF 4078])
(mem/s:DF (plus:SI (reg/f:SI 3275) (reg:SI 3812
REG_DEAD 3275
insn 5314 (set (reg:DF 4096)
(mem/s:DF (plus:SI (reg/f:SI 4082) (reg:SI 4084
After reload we end up
Mark Shinwell wrote:
The relevant RTL instructions before reload are as follows. These
correspond to points A, B and C respectively in my previous email.
I must admit I'm still stumbling in the dark a bit - this would be so
much easier to digest with a testcase.
The question I'm trying to
On Tue, May 15, 2007 at 04:27:21PM +0100, Mark Shinwell wrote:
Part of the reason for starting this thread was that I was concerned
about invalidating reloads that could be re-used later. However, it
seems to me that in every circumstance where the reload register is a
hard register and the
Rask Ingemann Lambertsen wrote:
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
[snip]
- the last use of reg2 (in B) is inside a matched input operand;
[snip]
The reload used for the instruction at B looks like this:
Reload 0: reload_in (SI) = (plus:SI (reg/f:SI 9 r9
On Tue, May 15, 2007 at 09:31:10AM +0100, Mark Shinwell wrote:
Rask Ingemann Lambertsen wrote:
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
[snip]
- the last use of reg2 (in B) is inside a matched input operand;
[snip]
The reload used for the instruction at B looks
Rask Ingemann Lambertsen wrote:
On Tue, May 15, 2007 at 09:31:10AM +0100, Mark Shinwell wrote:
Rask Ingemann Lambertsen wrote:
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
[snip]
- the last use of reg2 (in B) is inside a matched input operand;
[snip]
The reload used
Mark Shinwell wrote:
The bug is currently only exhibiting itself on a proprietary testcase
when compiled for an ARM target and is extremely sensitive to the
particular code involved. It arises as follows, using the same notation
as in Richard's mail:
If you can't post the testcase, the best
and many if() statements are even more complex
than the one you quote. It is fine to want to cover all eventualities, but
this is the fifth time someone runs into a reload inheritance bug since
about August 2006, so be realistic. I think changes to (except for rewrites
of) reload are best kept small
Rask Ingemann Lambertsen wrote:
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
I'm fairly certain that this is the correct approach to fix this
issue, but I'm less certain that I have correctly guarded the call
to forget_old_reloads_1, and indeed that I've done everything to
Bernd Schmidt wrote:
Mark Shinwell wrote:
The bug is currently only exhibiting itself on a proprietary testcase
when compiled for an ARM target and is extremely sensitive to the
particular code involved. It arises as follows, using the same notation
as in Richard's mail:
If you can't post
Mark Shinwell wrote:
These dumps are of course taken before the application of my patch.
Hope that helps,
Thanks. I may have missed it in the previous mails, but which piece of
code exactly decides to use R9 for reload 0 of insn 5314?
Bernd
--
This footer brought to you by insane German
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
I'm fairly certain that this is the correct approach to fix this
issue, but I'm less certain that I have correctly guarded the call
to forget_old_reloads_1,
[snip]
Index: reload1.c
Rask Ingemann Lambertsen wrote:
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
I'm fairly certain that this is the correct approach to fix this
issue, but I'm less certain that I have correctly guarded the call
to forget_old_reloads_1,
[snip]
Index: reload1.c
Bernd Schmidt wrote:
Mark Shinwell wrote:
These dumps are of course taken before the application of my patch.
Hope that helps,
Thanks. I may have missed it in the previous mails, but which piece of
code exactly decides to use R9 for reload 0 of insn 5314?
I'm afraid I'm not sure exactly
I have had the misfortune to discover a reload inheritance bug which,
after a long period of analysis, has turned out to be very similar to
the situation described by Richard Sandiford in
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01977.html.
This being my first serious foray into reload, I
In order to fix this I think that reload1.c:emit_reload_insns should,
at the point of discovery of an input reload whose reload register is a
non-spill hard register H, invalidate all previous reloads involving
that hard register.
If the reload is inherited, and there is no non-input part of
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
[snip]
- the last use of reg2 (in B) is inside a matched input operand;
[snip]
The reload used for the instruction at B looks like this:
Reload 0: reload_in (SI) = (plus:SI (reg/f:SI 9 r9 [3275])
29 matches
Mail list logo
