fno-branch-count-reg misleading documentation woes
hello,
The documentation for -fno-branch-count-reg explains that a
dec-and-test-branch instruction is replaced by an equivalent sequence of
instruction that decrement a register, compare it against 0, and branch.
(see the use of the world *instead*)
This is not really true, since this option firstly disables the loop
reversal transformation (loop-init.c::gate_rtl_doloop). As such, the
generated code will not necessary have an inversed decrement loop count
created and the sequence of reg testing will not be necessary a
decrement-test-branch sequence.
another comment: -fbranch-count-reg the instruction is not necessary a
"decrement and branch" but could also be a "decrement and compare" like
on the SH.
would a rephrasing like the following be more accurate ?
thanks.
-c
Index: invoke.texi
===
--- invoke.texi (revision 135611)
+++ invoke.texi (working copy)
@@ -5420,10 +5420,7 @@
@item -fno-branch-count-reg
@opindex fno-branch-count-reg
-Do not use ``decrement and branch'' instructions on a count register,
-but instead generate a sequence of instructions that decrement a
-register, compare it against zero, then branch based upon the result.
-This option is only meaningful on architectures that support such
+Do not use ``decrement and branch/compare'' instructions on a count
register. By setting this flag, loop inversion will be disabled. This
option is only meaningful on architectures that support such
instructions, which include x86, PowerPC, IA-64 and S/390.
The default is @option{-fbranch-count-reg}.
Implementing a restrictive addressing mode for a gcc port - Take 2
Hello all,
The target that i am working on is 16bit, big endian and with 16 registers.
It has this particular addressing mode
load Rd, Ra[offset]
store Rs, Ra[offset]
where the offset should be positive, base register Ra should be an
even register and for the source or the destination register Rd/Ra,
the restriction is
that it should be one more than the base register . So the following
instructions are valid:
load R5, R4[4]
store R11, R10[2]
while the following ones are wrong:
load R8, R6[4]
store R3, R8[2]
What i did to implement this is to have eight register classes with
each class having two registers, an even register and an odd register
then in define expand look for the register indirect with offset
addressing mode and emit gen_store_offset or gen_load_offset pattern
if the addressing mode is found. In the pattern i will have the 8
similar constraints for the base register and the source/destination
register. But this didn't work out properly, probably because i had
many patterns for movhi operations. So i tired what Jim Wilson
suggested to me when i posted this question earlier. What he suggested
was:
"One thing you could try is generating a double-word pseudo-reg at RTL
expand time, and then using subreg 0 for the source and subreg 1 for
the dest (or vice versa depending on endianness/word order). This
will get you a register pair you can use from the register allocator.
This doesn't help at reload time though.
You probably have to define a constraint for every register, and then
write an alternative for every register pair matching the correct even
register with the correct odd register. That gets you past reload."
So i did the following to implement his suggestion.
I have single define_expand and define_insn for movhi patterns. In
define_expand for movhi i have the folllowing
offset = INTVAL(XEXP(XEXP(mem_op, 0), 1));
dword = gen_reg_rtx (SImode);
base = simplify_gen_subreg (HImode, dword, SImode, 0);
if (mode == Pmode) {
reg_op = simplify_gen_subreg (HImode, dword, SImode, 2);
mem_op1 = gen_rtx_MEM (Pmode, plus_constant (base, offset));
}
else {
reg_op = simplify_gen_subreg (QImode, dword, SImode, 3);
mem_op1 = gen_rtx_MEM (QImode, plus_constant (base, offset));
}
if (GET_CODE (operands[0]) == MEM) {
operands[0] = mem_op1;
operands[1] = reg_op;
}
else if (GET_CODE (operands[1]) == MEM) {
operands[1] = mem_op1;
operands[0] = reg_op;
}
and in define_insn i have the following pattern:
(define_insn "*movhi_internal"
[(set (match_operand:HI 0 "nonimmediate_operand"
"=r,R01,R03,R05,R07,R09,R13,R15,r,U00,U02,U04,U06,U08,U12,U14,m,r")
(match_operand:HI 1 "general_operand"
"r,U00,U02,U04,U06,U08,U12,U14,m,R01,R03,R05,R07,R09,R13,R15,r,i"))]
where Uxx is memory constraints and Rxx is register constraints.
After implementing this i came across this problem:
(insn 12 11 13 1 (set (reg/f:HI 24)
(mem/c/i:HI (reg/f:HI 25) [0 m+0 S2 A16])) -1 (nil)
(nil))
(insn 13 12 14 1 (set (subreg:QI (reg:SI 28) 3)
(mem:QI (plus:HI (subreg:HI (reg:SI 28) 0)
(const_int 1 [0x1])) [0 S1 A8])) -1 (nil)
(nil))
(insn 14 13 15 1 (set (reg:HI 26)
(zero_extend:HI (reg:QI 27))) -1 (nil)
(nil))
For zero-extend both operands should be in registers. So one operand
which was previously in memory is moved to reg27 through load
operations(insn 13). Since for this offset addressing mode is used
define_expand for movqi will generate SImode register, reg28 and does
the operations. But this is not reflected in the subsequent
instructions (insn 14). And hence insn 13 is getting deleted as its
operands are never used.
What i am i doing wrong? Am i implementing the addressing mode properly?
Any help is appreciated.
Regards,
Shafi
[EMAIL PROTECTED]: Results for 4.4.0 20080528 (experimental) [trunk revision 136068] (GCC) testsuite on v850-unknown-elf]
This regression came through just today... --- Start of forwarded message --- Date: Wed, 28 May 2008 09:23:10 -0400 From: DJ Delorie <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Results for 4.4.0 20080528 (experimental) [trunk revision 136068] (GCC) testsuite on v850-unknown-elf gcc result changes... Multilib: v850-sim PASS-XFAIL: gcc.dg/tree-ssa/loadpre8.c scan-tree-dump-times pre "Eliminated: 1" 1 LAST_UPDATED: Wed May 28 06:02:08 UTC 2008 (revision 136068) Target is v850-unknown-elf Host is i686-pc-linux-gnu Compiler version: 4.4.0 20080528 (experimental) [trunk revision 136068] (GCC) Platform: v850-unknown-elf configure flags: --prefix=/sata/dj/gnu/install --target=v850-elf --enable-languages=c,c++ --with-newlib --with-headers --with-mpfr=/usr/local --- End of forwarded message ---
[EMAIL PROTECTED]: Results for 4.4.0 20080528 (experimental) [trunk revision 136068] (GCC) testsuite on m32c-unknown-elf]
Same regression, but m32c is overall better since yesterday :-) --- Start of forwarded message --- Date: Wed, 28 May 2008 06:57:46 -0400 From: DJ Delorie <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Results for 4.4.0 20080528 (experimental) [trunk revision 136068] (GCC) testsuite on m32c-unknown-elf gcc result changes... Multilib: m32c-sim/-mcpu=m16c FAIL-PASS: gcc.dg/tree-ssa/ifc-20040816-2.c (test for excess errors) FAIL-PASS: gcc.dg/tree-ssa/ifc-20040816-2.c scan-tree-dump-times ifcvt "Applying if-conversion" 1 PASS-XFAIL: gcc.dg/tree-ssa/loadpre8.c scan-tree-dump-times pre "Eliminated: 1" 1 FAIL-PASS: gcc.dg/tree-ssa/pr32540-1.c (test for excess errors) FAIL-PASS: gcc.dg/tree-ssa/pr32540-2.c (test for excess errors) FAIL-PASS: gcc.dg/tree-ssa/ssa-lim-5.c (test for excess errors) Multilib: m32c-sim/-mcpu=m32c FAIL-PASS: gcc.dg/tree-ssa/ifc-20040816-2.c (test for excess errors) FAIL-PASS: gcc.dg/tree-ssa/ifc-20040816-2.c scan-tree-dump-times ifcvt "Applying if-conversion" 1 FAIL-XFAIL: gcc.dg/tree-ssa/loadpre8.c scan-tree-dump-times pre "Eliminated: 1" 1 FAIL-PASS: gcc.dg/tree-ssa/pr32540-1.c (test for excess errors) FAIL-PASS: gcc.dg/tree-ssa/pr32540-2.c (test for excess errors) FAIL-PASS: gcc.dg/tree-ssa/ssa-lim-5.c (test for excess errors) LAST_UPDATED: Wed May 28 06:02:08 UTC 2008 (revision 136068) Target is m32c-unknown-elf Host is i686-pc-linux-gnu Compiler version: 4.4.0 20080528 (experimental) [trunk revision 136068] (GCC) Platform: m32c-unknown-elf configure flags: --prefix=/sata/dj/gnu/install --target=m32c-elf --enable-languages=c,c++ --with-newlib --with-headers --with-mpfr=/usr/local --- End of forwarded message ---
Statement expressions problem returning arrays.
Hello. I have some complex statement-expressions that I am having trouble with
and this seemed like the more technical mailing list. I have boiled them down
to these small examples:
#1:
#define copyof(str) ({ char buf[sizeof(str)]; strcpy(buf, str); buf; })
int main(int argc, char **argv) {
printf("%s %s\n", copyof("hello"), copyof("world"));
}
That produces the output "hello world" when compiled with no optimization, but
"hello hello" when compiled with -O or greater (but not with just the flags
enabled by -O). It was my impression that a character array allocated on the
stack was kind of like a value rather than a pointer (like char arrays are
inside a struct), so it seems like the statement-expression should be returning
a copy of the whole array rather than a copy of a pointer to its previous
location on the stack.
#2:
#define copyof(str) ({ char buf[128]; strcpy(buf, str); buf; })
int main(int argc, char **argv) {
printf("%s %s\n", copyof("hello"), copyof("world"));
}
That produces "hello hello" no matter what optimization is used.
#3:
struct copy { char buf[128]; };
#define copyof(str) ({ struct copy cp; strcpy(cp.buf, str); cp; }).buf
int main(int argc, char **argv) {
printf("%s %s\n", copyof("hello"), copyof("world"));
}
Memory fault.
#4:
struct copy { char buf[128]; };
#define copyof(str) ({ struct copy cp; strcpy(cp.buf, str); cp; }).buf
int main(int argc, char **argv) {
printf("%s %s\n", copyof("hello"), copyof("world"));
}
That 'correctly' produces "hello world" with any optimization level.
So my question is, are those all the expected behavior (#1 through #3 are not
valid)? From my 'ok' knowledge of C and gnu extensions it seems like all four
should produce "hello world".
These results are from 4.1.2 and 4.2.3 on Gentoo, processor is Pentium M.
Includes for stdio, string not shown.
Re: Statement expressions problem returning arrays.
Sorry, bad proofreading. The #4 example should read:
struct copy { char buf[128]; };
#define copyof(str) &({ struct copy cp; strcpy(cp.buf, str); cp; }).buf[0]
int main(int argc, char **argv) {
printf("%s %s\n", copyof("hello"), copyof("world"));
}
-Original Message-
>From: Jamax <[EMAIL PROTECTED]>
>Sent: May 28, 2008 12:07 PM
>To: gcc@gcc.gnu.org
>Subject: Statement expressions problem returning arrays.
>
>Hello. I have some complex statement-expressions that I am having trouble
>with and this seemed like the more technical mailing list. I have boiled them
>down to these small examples:
>
>#1:
>
>#define copyof(str) ({ char buf[sizeof(str)]; strcpy(buf, str); buf; })
>int main(int argc, char **argv) {
> printf("%s %s\n", copyof("hello"), copyof("world"));
>}
>
>That produces the output "hello world" when compiled with no optimization, but
>"hello hello" when compiled with -O or greater (but not with just the flags
>enabled by -O). It was my impression that a character array allocated on the
>stack was kind of like a value rather than a pointer (like char arrays are
>inside a struct), so it seems like the statement-expression should be
>returning a copy of the whole array rather than a copy of a pointer to its
>previous location on the stack.
>
>#2:
>
>#define copyof(str) ({ char buf[128]; strcpy(buf, str); buf; })
>int main(int argc, char **argv) {
> printf("%s %s\n", copyof("hello"), copyof("world"));
>}
>
>That produces "hello hello" no matter what optimization is used.
>
>#3:
>
>struct copy { char buf[128]; };
>#define copyof(str) ({ struct copy cp; strcpy(cp.buf, str); cp; }).buf
>int main(int argc, char **argv) {
> printf("%s %s\n", copyof("hello"), copyof("world"));
>}
>
>Memory fault.
>
>#4:
>
>struct copy { char buf[128]; };
>#define copyof(str) ({ struct copy cp; strcpy(cp.buf, str); cp; }).buf
>int main(int argc, char **argv) {
> printf("%s %s\n", copyof("hello"), copyof("world"));
>}
>
>That 'correctly' produces "hello world" with any optimization level.
>
>So my question is, are those all the expected behavior (#1 through #3 are not
>valid)? From my 'ok' knowledge of C and gnu extensions it seems like all four
>should produce "hello world".
>
>These results are from 4.1.2 and 4.2.3 on Gentoo, processor is Pentium M.
>Includes for stdio, string not shown.
>
Re: GCC 4.1 snapshots
Gerald Pfeifer wrote: At this point, we have three open release branches (4.1, 4.2, and 4.3) and trunk. Currently we are generating weekly snapshots for all four of these. I agree that turning off the 4.1 snapshots makes sense. If you're sufficiently motivated to do the automatic snapshot-only-if-something-changed, that seems fine too -- but from the FSF point of view 4.1 is now dormant. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: [EMAIL PROTECTED]: Results for 4.4.0 20080528 (experimental) [trunk revision 136068] (GCC) testsuite on v850-unknown-elf]
If i read this right, it says it was a pass, and is now an XFAIL? If so, that is the expected result of Richi's patch, and he mentioned it when he changed it to xfail On Wed, May 28, 2008 at 10:26 AM, DJ Delorie <[EMAIL PROTECTED]> wrote: > > This regression came through just today... > > --- Start of forwarded message --- > Date: Wed, 28 May 2008 09:23:10 -0400 > From: DJ Delorie <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Results for 4.4.0 20080528 (experimental) [trunk revision 136068] > (GCC) testsuite on v850-unknown-elf > > gcc result changes... > > Multilib: v850-sim > PASS-XFAIL: gcc.dg/tree-ssa/loadpre8.c scan-tree-dump-times pre "Eliminated: > 1" 1 > > > LAST_UPDATED: Wed May 28 06:02:08 UTC 2008 (revision 136068) > > Target is v850-unknown-elf > Host is i686-pc-linux-gnu > > > Compiler version: 4.4.0 20080528 (experimental) [trunk revision 136068] (GCC) > Platform: v850-unknown-elf > configure flags: --prefix=/sata/dj/gnu/install --target=v850-elf > --enable-languages=c,c++ --with-newlib --with-headers --with-mpfr=/usr/local > --- End of forwarded message --- >
Re: GCC 4.1 snapshots
On Tue, May 27, 2008 at 09:11:18PM -0400, NightStrike wrote: > On 5/27/08, Joe Buck <[EMAIL PROTECTED]> wrote: > > A third alternative is to issue a snapshot (at whatever time interval > > is chosen) iff there's been a checkin on the branch. > > I thought that's how it worked already. No, a new 4.1 snapshot was created May 26, even though the last checkin was April 8.
Re: [EMAIL PROTECTED]: Results for 4.4.0 20080528 (experimental) [trunk revision 136068] (GCC) testsuite on v850-unknown-elf]
> If i read this right, it says it was a pass, and is now an XFAIL? Yes. > If so, that is the expected result of Richi's patch, and he > mentioned it when he changed it to xfail Ok.
Re: GCC 4.1 snapshots
On Wed, May 28, 2008 at 7:13 PM, Joe Buck <[EMAIL PROTECTED]> wrote: > On Tue, May 27, 2008 at 09:11:18PM -0400, NightStrike wrote: >> On 5/27/08, Joe Buck <[EMAIL PROTECTED]> wrote: >> > A third alternative is to issue a snapshot (at whatever time interval >> > is chosen) iff there's been a checkin on the branch. >> >> I thought that's how it worked already. > > No, a new 4.1 snapshot was created May 26, even though the last checkin > was April 8. That's because the tree is still daily updated with the DATESTAMP changes. Richard.
Re: GCC 4.1 snapshots
On Wed, May 28, 2008 at 08:15:20PM +0200, Richard Guenther wrote: > On Wed, May 28, 2008 at 7:13 PM, Joe Buck <[EMAIL PROTECTED]> wrote: > > On Tue, May 27, 2008 at 09:11:18PM -0400, NightStrike wrote: > >> On 5/27/08, Joe Buck <[EMAIL PROTECTED]> wrote: > >> > A third alternative is to issue a snapshot (at whatever time interval > >> > is chosen) iff there's been a checkin on the branch. > >> > >> I thought that's how it worked already. > > > > No, a new 4.1 snapshot was created May 26, even though the last checkin > > was April 8. > > That's because the tree is still daily updated with the DATESTAMP changes. Ah. Then the DATESTAMP change shouldn't happen if there is no modification to the branch since the last DATESTAMP.
Re: Help with reload and naked constant sum causing ICE
Andy H <[EMAIL PROTECTED]> writes:
>> If L_R_A does nothing with it,
>> the normal reload handling will first try:
>>
>> (const:HI (plus:HI (symbol_ref:HI ("chk_fail_buf") (const_int 2
>>
>
> This worked just as your described after I added test of
> reg_equiv_constant[] inside L_R_A .
>
> So I guess that looks like the fix for bug I posted.
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34641
>
> To summarize
>
> LEGITIMIZE_RELOAD_ADDRESS should now always check reg_equiv_constant
> before it trying to do any push_reload of register.
TBH, I still think AVR is doing far too much in L_R_A. To quote
the current version:
#define LEGITIMIZE_RELOAD_ADDRESS(X, MODE, OPNUM, TYPE, IND_LEVELS, WIN)\
do {\
if (1&&(GET_CODE (X) == POST_INC || GET_CODE (X) == PRE_DEC)) \
{ \
push_reload (XEXP (X,0), XEXP (X,0), &XEXP (X,0), &XEXP (X,0),\
POINTER_REGS, GET_MODE (X),GET_MODE (X) , 0, 0, \
OPNUM, RELOAD_OTHER);\
goto WIN; \
} \
Why does AVR need different POST_INC and PRE_DEC handling from
other auto-inc targets? This at least deserves a comment.
But really, you should just let reload handle this case.
Does reload currently lack some support you need?
if (GET_CODE (X) == PLUS \
&& REG_P (XEXP (X, 0))\
&& GET_CODE (XEXP (X, 1)) == CONST_INT\
&& INTVAL (XEXP (X, 1)) >= 1) \
{ \
int fit = INTVAL (XEXP (X, 1)) <= (64 - GET_MODE_SIZE (MODE));\
if (fit) \
{ \
if (reg_equiv_address[REGNO (XEXP (X, 0))] != 0) \
{ \
int regno = REGNO (XEXP (X, 0)); \
rtx mem = make_memloc (X, regno); \
push_reload (XEXP (mem,0), NULL, &XEXP (mem,0), NULL, \
POINTER_REGS, Pmode, VOIDmode, 0, 0, \
1, ADDR_TYPE (TYPE));\
push_reload (mem, NULL_RTX, &XEXP (X, 0), NULL, \
BASE_POINTER_REGS, GET_MODE (X), VOIDmode, 0, 0, \
OPNUM, TYPE);\
goto WIN; \
} \
push_reload (XEXP (X, 0), NULL_RTX, &XEXP (X, 0), NULL, \
BASE_POINTER_REGS, GET_MODE (X), VOIDmode, 0, 0, \
OPNUM, TYPE);\
goto WIN; \
} \
else if (! (frame_pointer_needed && XEXP (X,0) == frame_pointer_rtx)) \
{ \
push_reload (X, NULL_RTX, &X, NULL, \
POINTER_REGS, GET_MODE (X), VOIDmode, 0, 0, \
OPNUM, TYPE);\
goto WIN; \
} \
} \
} while(0)
These too don't make much immediate sense to me. What are they trying
to do that reload wouldn't do otherwise?
Rather than duplicating more of reload's checks in this macro, I think
it would be better to strip it down as far as possible.
There's a bit of self-interest here. It makes it very hard to work on
reload if ports try to duplicate so much of the logic in target-specific
files.
Richard
Re: Help with reload and naked constant sum causing ICE
Richard,
I appreciate the extra input.
I agree with what you say. The target should not be doing middle-end
stuff .
The inc/dec and (Rxx) != (frame pointer) parts just reload using
pointer class
which is a one extra register than base pointers but the extra reg
cannot take offset.
However, I dont know what reload can - or cannot do - (but I'm learning
that every day)
I do not know fully what was intended by all of AVR L_R_A and how
this might now be redundant, useful or wrong.
I already have patch with maintainer that takes out a chunk of this to
fix another (spill) bug.
I have copied Anatoly for comment, and I promise to revisit this again
after reviewing reload capabilities.
Andy
-Original Message-
From: Richard Sandiford <[EMAIL PROTECTED]>
To: Andy H <[EMAIL PROTECTED]>
Cc: GCC Development ; [EMAIL PROTECTED]
Sent: Wed, 28 May 2008 3:00 pm
Subject: Re: Help with reload and naked constant sum causing ICE
Andy H <[EMAIL PROTECTED]> writes:
If L_R_A does nothing with it,
the normal reload handling will first try:
(const:HI (plus:HI (symbol_ref:HI ("chk_fail_buf") (const_int 2
This worked just as your described after I added test of
reg_equiv_constant[] inside L_R_A .
So I guess that looks like the fix for bug I posted.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34641
To summarize
LEGITIMIZE_RELOAD_ADDRESS should now always check reg_equiv_constant
before it trying to do any push_reload of register.
TBH, I still think AVR is doing far too much in L_R_A. To quote
the current version:
#define LEGITIMIZE_RELOAD_ADDRESS(X, MODE, OPNUM, TYPE, IND_LEVELS,
WIN)\
do {\
if (1&&(GET_CODE (X) == POST_INC || GET_CODE (X) == PRE_DEC)) \
{ \
push_reload (XEXP (X,0), XEXP (X,0), &XEXP (X,0), &XEXP (X,0),
\
POINTER_REGS, GET_MODE (X),GET_MODE (X) , 0, 0, \
OPNUM, RELOAD_OTHER);\
goto WIN; \
} \
Why does AVR need different POST_INC and PRE_DEC handling from
other auto-inc targets? This at least deserves a comment.
But really, you should just let reload handle this case.
Does reload currently lack some support you need?
if (GET_CODE (X) == PLUS \
&& REG_P (XEXP (X, 0))\
&& GET_CODE (XEXP (X, 1)) == CONST_INT\
&& INTVAL (XEXP (X, 1)) >= 1) \
{ \
int fit = INTVAL (XEXP (X, 1)) <= (64 - GET_MODE_SIZE (MODE));
\
if (fit) \
{ \
if (reg_equiv_address[REGNO (XEXP (X, 0))] != 0) \
{ \
int regno = REGNO (XEXP (X, 0)); \
rtx mem = make_memloc (X, regno); \
push_reload (XEXP (mem,0), NULL, &XEXP (mem,0), NULL,
\
POINTER_REGS, Pmode, VOIDmode, 0, 0, \
1, ADDR_TYPE (TYPE));\
push_reload (mem, NULL_RTX, &XEXP (X, 0), NULL, \
BASE_POINTER_REGS, GET_MODE (X), VOIDmode, 0, 0, \
OPNUM, TYPE);\
goto WIN; \
} \
push_reload (XEXP (X, 0), NULL_RTX, &XEXP (X, 0), NULL, \
BASE_POINTER_REGS, GET_MODE (X), VOIDmode, 0, 0, \
OPNUM, TYPE);\
goto WIN; \
} \
else if (! (frame_pointer_needed && XEXP (X,0) ==
frame_pointer_rtx)) \
{ \
push_reload (X, NULL_RTX, &X, NULL, \
POINTER_REGS, GET_MODE (X), VOIDmode, 0, 0, \
OPNUM, TYPE);\
goto WIN; \
} \
} \
} while(0)
These too don't make much immediate sense to me. What are they trying
to do that reload wouldn't do otherwise?
Rather than duplicating more of reload's checks in this macro, I think
it would be better to strip it down as far as possible.
There's a bit of self-interest here. It makes it very hard to work on
reload if ports try to duplicate so much of the logic in target-specific
files.
Richard
Re: Help with reload and naked constant sum causing ICE
[EMAIL PROTECTED] writes: > I have copied Anatoly for comment, and I promise to revisit this again > after reviewing reload capabilities. Thanks. Looking back, my message sounded like I was holding you personally responsible for the current AVR macro. Didn't mean to do that ;) Richard
Re: MIPS stack frame question
Masao Uebayashi <[EMAIL PROTECTED]> writes:
> - In gcc/config/mips/mips.c:mips_compute_frame_info() you do
>
> /* Move above the GPR save area. */
> if (frame->num_gp > 0)
> {
> offset += MIPS_STACK_ALIGN (frame->num_gp * UNITS_PER_WORD);
> frame->gp_sp_offset = offset - UNITS_PER_WORD;
> }
>
> So what is "- UNITS_PER_WORD" for?
Well, the fields are defined as follows:
/* The offset of the topmost GPR and FPR save slots from the top of
the frame, or zero if no such slots are needed. */
HOST_WIDE_INT gp_save_offset;
HOST_WIDE_INT fp_save_offset;
/* Likewise, but giving offsets from the bottom of the frame. */
HOST_WIDE_INT gp_sp_offset;
HOST_WIDE_INT fp_sp_offset;
so the "- UNITS_PER_WORD" converts the offset of the end/top of the save
slot area to the offset of the topmost save slot.
> - Why do you put MIPS_STACK_ALIGN in many places?
TBH, I just blindly kept these when doing the rewrite. Some of them
aren't needed, as you say; I'll try to fix that sometime.
It isn't just the bottom of the stack that needs to be aligned though.
Addressable regions like the local variables and the varargs save area
must also be aligned, so that the alignment attributes work correctly.
Richard
Re: Help with reload and naked constant sum causing ICE
Richard Sandiford wrote:
Andy H <[EMAIL PROTECTED]> writes:
If L_R_A does nothing with it,
the normal reload handling will first try:
(const:HI (plus:HI (symbol_ref:HI ("chk_fail_buf") (const_int 2
This worked just as your described after I added test of
reg_equiv_constant[] inside L_R_A .
So I guess that looks like the fix for bug I posted.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34641
To summarize
LEGITIMIZE_RELOAD_ADDRESS should now always check reg_equiv_constant
before it trying to do any push_reload of register.
TBH, I still think AVR is doing far too much in L_R_A. To quote
the current version:
[...]
Not only should there be some comments, those comments should clearly
explain how L_R_A is improving the generated code. That is LRA's job,
to implement target specific reload strategies which improve the
generated code. If the AVR port is using L_R_A for *correctness*, then
the AVR port is broken.
Interestingly enough, we've seen a fair amount of commonality in L_R_A
implementations (particularly in dealing with out-of-range offsets in
reg+d addressing modes). It probably wouldn't be terribly difficult to
factor that code into reload itself and do away with a significant hunk
of the existing L_R_A implementations.
Jeff
gcc-4.2-20080528 is now available
Snapshot gcc-4.2-20080528 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080528/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 136131 You'll find: gcc-4.2-20080528.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20080528.tar.bz2 C front end and core compiler gcc-ada-4.2-20080528.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20080528.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20080528.tar.bz2 C++ front end and runtime gcc-java-4.2-20080528.tar.bz2 Java front end and runtime gcc-objc-4.2-20080528.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20080528.tar.bz2The GCC testsuite Diffs from 4.2-20080521 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: MIPS stack frame question
> > - In gcc/config/mips/mips.c:mips_compute_frame_info() you do
> >
> > /* Move above the GPR save area. */
> > if (frame->num_gp > 0)
> > {
> > offset += MIPS_STACK_ALIGN (frame->num_gp * UNITS_PER_WORD);
> > frame->gp_sp_offset = offset - UNITS_PER_WORD;
> > }
> >
> > So what is "- UNITS_PER_WORD" for?
>
> Well, the fields are defined as follows:
>
> /* The offset of the topmost GPR and FPR save slots from the top of
> the frame, or zero if no such slots are needed. */
> HOST_WIDE_INT gp_save_offset;
> HOST_WIDE_INT fp_save_offset;
>
> /* Likewise, but giving offsets from the bottom of the frame. */
> HOST_WIDE_INT gp_sp_offset;
> HOST_WIDE_INT fp_sp_offset;
>
> so the "- UNITS_PER_WORD" converts the offset of the end/top of the save
> slot area to the offset of the topmost save slot.
Understood, thanks.
And now I look at the Figure 7-2 in [1], it's clearly explained there.
I should have read carefully.
> > - Why do you put MIPS_STACK_ALIGN in many places?
>
> TBH, I just blindly kept these when doing the rewrite. Some of them
> aren't needed, as you say; I'll try to fix that sometime.
>
> It isn't just the bottom of the stack that needs to be aligned though.
> Addressable regions like the local variables and the varargs save area
> must also be aligned, so that the alignment attributes work correctly.
Understood too.
(If it's the only reason, GPR and FPR save don't need alignment - but
who cares? :)
Masao
