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
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:
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
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
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
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
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
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
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
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
I am currently involved in building GCC toolchains by configuring them with
the prefix that is to be used on the target system (somewhere in /opt)
and then installing them in a separate working installation directory
(say somewhere in my scratch space). The installation step into this
working
[EMAIL PROTECTED] wrote:
From: Mark Shinwell [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
My port, based on (GCC) 4.2.0 20061002 (experimental), is producing
incorrect code for the following test case:
[snip]
I've only had a very quick look at your code, but I have a feeling
thatthis
[EMAIL PROTECTED] wrote:
My port, based on (GCC) 4.2.0 20061002 (experimental), is producing
incorrect code for the following test case:
[snip]
I've only had a very quick look at your code, but I have a feeling that
this is an instance of the kind of slip-up with GO_IF_MODE_DEPENDENT_ADDRESS
Ian Ollmann wrote:
stronger type checking seems like a good idea to me in general.
I agree, but I don't really want to break lots of code all at once,
even if that code is being slightly more slack than it perhaps ought
to be :-)
Given that no-one has really objected to stronger type-checking
Ian Lance Taylor wrote:
I would vote for: break the code, but provide an option to restore the
old behaviour, and mention the option in the error message.
I like this -- I shall prepare a patch and circulate it for review.
Mark
Ian Lance Taylor wrote:
Mark Shinwell [EMAIL PROTECTED] writes:
I would now like to propose that the check in that function be made
even stronger such that it disallows conversions between vectors
whose element types differ -- even if an implicit conversion exists
between those element types
Currently we permit implicit conversions between vectors whose total
bitsizes are equal but which are divided into differing numbers of subparts.
It seems that in some circumstances this rule is overly lax. For example
the following code, using vector types (whose definitions I have provided
Ian Lance Taylor wrote:
I believe that the problem with changing this unconditionally is that
the Altivec programming guidelines specify the rules which gcc
currently follows: you are permitted to assign one vector variable to
another, without an explicit cast, when the vectors are the same
Richard Earnshaw wrote:
I'm not keen on this. On some machines a frame pointer is *very*
expensive, both in terms of the code required to set it up, and the
resulting loss of a register which affects code quality (in addition, on
Thumb, the frame pointer can access much less data on the stack
David Edelsohn wrote:
Mark Shinwell writes:
Mark If the hard frame pointer is forced by default, then targets which are
Mark particularly badly affected can simply define INITIAL_FRAME_ADDRESS_RTX.
Mark Since such targets would presumably not have to force reload to keep
Mark the frame pointer
Mark Mitchell wrote:
Mark Shinwell wrote:
As for the remaining problem, I suggest that we could:
(i) always return the hard frame pointer, and disable FP elimination in
the current function; or
(iii) ...the same as option (i), but allow targets to define another macro
that will cause
Hi,
I'd like to gather some opinions and advice on the expansion of
__builtin_frame_address, as discussed on gcc-patches last year [1, 2].
This centres on the following comment in expand_builtin_return_addr
arising from revision 103294 last year:
/* For a zero count, we don't care what frame
25 matches
Mail list logo
