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 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 a
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 t
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
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 all code I've tried
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(R
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:
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
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 your
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 in
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 (se
Bernd Schmidt wrote:
My gut feeling is that this example will work as a consequence.
... note that I inserted 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 the end of emit
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 i
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 an
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 t
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 --
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
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
> ===
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
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 the
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
era
e fix for this bug cover all eventualities
> in terms of the various varieties of reload that might arise, if
> possible...
Reload is 15000+ lines 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 tim
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 be
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 for
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
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 [3275
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])
>
> 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
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
30 matches
Mail list logo
