define_split
Hi all, I am trying to use define_split, but it seems to me that I don't understand how it is used. It says in the gccint.pdf (which I use as my tutorial (is there anything better or more up to date?)) that the combiner only uses the define_split if it doesn't find any define_insn to match. This is not clear to me: If there is no define_insn to match a pattern in the combine stage, then how is this pattern there in the first place? The only way I can think for it to happen is that such a pattern was created by the combiner itself (but it seems unreasonable to me that we now want to split what the combiner just combined). Can someone please explain this to me? Thanks, Roy.
Re: peephole2: dead regs not marked as dead
On 10/22/2010 01:16 PM, Georg Lay wrote: I already tried to fix this by introducing a different return-pattern, i.e. a PARALLEL of return and bunch of clobbers of unused regs. That fixes this problem but has many other disadvantages compared to a simple return. What were this disadvantages? Paolo
Re: peephole2: dead regs not marked as dead
Paolo Bonzini schrieb:
> On 10/27/2010 04:30 PM, Georg Lay wrote:
>> The first time it occurs in "exit block uses" is in pro/epilogue:
>>
>> peep2.c.193r.split2:;; exit block uses 2 [d2] 26 [SP] 27 [a11]
>> peep2.c.195r.pro_and_epilogue:;; exit block uses2 [d2] 15
>> [d15] 26 [SP]
>> 27 [a11]
>> peep2.c.196r.dse2:;; exit block uses2 [d2] 15 [d15] 26 [SP] 27 [a11]
>> peep2.c.196r.dse2:;; exit block uses2 [d2] 15 [d15] 26 [SP] 27 [a11]
>
> Oh, that helps a lot: this is what df_get_exit_block_use_set says:
>
> if (HAVE_epilogue && epilogue_completed)
> {
> /* Mark all call-saved registers that we actually used. */
> for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
> if (df_regs_ever_live_p (i) && !LOCAL_REGNO (i)
> && !TEST_HARD_REG_BIT (regs_invalidated_by_call, i))
> bitmap_set_bit (exit_block_uses, i);
> }
>
> These uses are needed to ensure that, if restores of call-saved
> registers are explicitly in the RTL for the epilogue, they are not
> considered dead. However, they make d15 live.
Yeah! That's it. Totally happy :-)
I implemented Hook LOCAL_REGNO and it works as expected. The machine actually
has no register windows resp. only a "trivial window" with IN_REGNO==OUT_REGNO
for all passed REGs. However, with a proper definition of LOCAL_REGNO I see the
dead-notes and the code is as expected.
I hope LOCAL_REGNO has no undesired side effects. Even the stack pointer (reg 26
[SP] above) is an element of LOCAL_REGNO, which means that if a function needs a
frame, e.g. alloca, there is no need to explicitly restore SP before returning.
> It looks like you need to represent the definition of call-saved
> registers explicitly in the RTL for the epilogue. These definitions
> will make d15 dead as you expect, and you need them even if they will
> not output any assembly.
Emitting a bunch of CLOBBERs in epilogue/sibcall_epilogue works also, at least
for the small example above. But using LOCAL_REGNO seems more natural to me and
that does not clutter RTL.
> In this sense, this is a backend bug: you are not making the RTL stream
> accurate, and it's biting you. I acknowledge it's quite tricky; from
> what I understood it happens because of a peculiarity of your
> architecture with respect to callee-save registers (d15 is automatically
> save/restored, or something like that).
Yes. From gcc's point of view it's a hermaphrodite caller-saves and
callee-restores machine where all saves/restores are handled by the hardware and
no code is needed. CALLs save the call-saved regs and invalidate(sic!) them.
When the callee-code starts the content of call-saved regs is undefined (except
SP). So these regs cannot be used to pass params. The RETURN implicitly restores
these registers, the values coming out of the blue (not from the stack). This
introduces overhead in runtime because all call-saved regs get saved/restored no
matter if they are actually used or not. However, code density is good (at least
for prologues and epilogues).
I already had to fix IRA and remove the following part of
ira-color.c::assign_hard_reg() because it makes assumptions that do not hold for
the machine:
if (! allocated_hardreg_p[hard_regno]
&& ira_hard_reg_not_in_set_p (hard_regno, mode, call_used_reg_set))
/* We need to save/restore the hard register in
epilogue/prologue. Therefore we increase the cost. */
{
/* ??? If only part is call clobbered. */
rclass = REGNO_REG_CLASS (hard_regno);
add_cost = (ira_memory_move_cost[mode][rclass][0]
+ ira_memory_move_cost[mode][rclass][1] - 1);
cost += add_cost;
full_cost += add_cost;
}
Thanks a lot for pointing me to the right place!
Georg
Re: peephole2: dead regs not marked as dead
On 10/28/2010 12:24 PM, Georg Lay wrote:
Emitting a bunch of CLOBBERs in epilogue/sibcall_epilogue works also, at least
for the small example above. But using LOCAL_REGNO seems more natural to me and
that does not clutter RTL.
True. It's a pretty elegant solution, and I missed it in my mail (I'm
not really a backend guy at all, which explains why it's easy for me to
blame backends).
I already had to fix IRA and remove the following part of
ira-color.c::assign_hard_reg() because it makes assumptions that do not hold for
the machine:
if (! allocated_hardreg_p[hard_regno]
&& ira_hard_reg_not_in_set_p (hard_regno, mode, call_used_reg_set))
/* We need to save/restore the hard register in
epilogue/prologue. Therefore we increase the cost. */
{
/* ??? If only part is call clobbered. */
rclass = REGNO_REG_CLASS (hard_regno);
add_cost = (ira_memory_move_cost[mode][rclass][0]
+ ira_memory_move_cost[mode][rclass][1] - 1);
cost += add_cost;
full_cost += add_cost;
}
Maybe you can use LOCAL_REGNO here too, and submit a patch for that?
Paolo
Re: peephole2: dead regs not marked as dead
Paolo Bonzini schrieb:
> On 10/22/2010 01:16 PM, Georg Lay wrote:
>> I already tried to fix this by introducing a different return-pattern,
>> i.e. a
>> PARALLEL of return and bunch of clobbers of unused regs. That fixes
>> this problem
>> but has many other disadvantages compared to a simple return.
>
> What were this disadvantages?
Suppose the following snip from libm's cosh computation. We are in pass DCE
somewhere after peephole2 and before BBRO:
;; d2 = d4 * d6
(call_insn/u 16 250 17 3 e_cosh.c:926 (parallel [
(set (reg:DF 2 d2)
(call (mem:HI (symbol_ref:SI ("__d_mul") [flags 0x41]) [0 S2
A16])
(const_int 0 [0x0])))
(use (const_int 0 [0x0]))
]) 92 {call_value_insn}
(expr_list:REG_DEP_TRUE (use (reg:DF 6 d6))
(expr_list:REG_DEP_TRUE (use (reg:DF 4 d4))
(nil
;; d8 = d2
(insn 17 16 209 3 e_cosh.c:926 (set (reg/v:DF 8 d8 [orig:39 w ] [39])
(reg:DF 2 d2)) 15 {*movdf_insn} (nil))
;; goto 161
(jump_insn 209 17 210 3 e_cosh.c:926 (set (pc)
(label_ref 161)) 84 {jump} (nil)
-> 161)
..
;; 161:
;; Pred edge 14 [100.0%] (fallthru)
;; Pred edge 5 [50.0%]
;; Pred edge 3 [100.0%]
;; Pred edge 6 [100.0%]
;; Pred edge 8 [100.0%]
;; Pred edge 10 [100.0%]
;; Pred edge 13 [100.0%]
(code_label 161 159 162 15 3 "" [6 uses])
(note 162 161 167 15 [bb 15] NOTE_INSN_BASIC_BLOCK)
;; d2 = d8
(insn 167 162 170 15 e_cosh.c:956 (set (reg/i:DF 2 d2)
(reg/v:DF 8 d8 [orig:39 w ] [39])) 15 {*movdf_insn} (nil))
(insn 170 167 247 15 e_cosh.c:956 (use (reg/i:DF 2 d2)) -1 (nil))
(note 247 170 248 15 NOTE_INSN_EPILOGUE_BEG)
;; return d2
(jump_insn 248 247 249 15 e_cosh.c:956 (return) 119 {return_insn} (nil))
;; End of basic block 15 -> ( 1)
So d8 (call-saved) is set in several places and just copied to the return
register d2. Up to now the function hat just one exit in bb 15.
The BB reordering now copies the small part bb 15 of the return code and removes
jump insns like 209. the BBRO dump then is:
;; d8 = d4 * d6
(call_insn/u 16 250 17 10 e_cosh.c:926 (parallel [
(set (reg:DF 2 d2)
(call (mem:HI (symbol_ref:SI ("__d_mul") ...
;; d8 = d2
(insn 17 16 256 10 e_cosh.c:926 (set (reg/v:DF 8 d8 [orig:39 w ] [39])
(reg:DF 2 d2)) 15 {*movdf_insn} (nil))
;; d2 = d8
(insn 256 17 257 10 e_cosh.c:956 (set (reg/i:DF 2 d2)
(reg/v:DF 8 d8 [orig:39 w ] [39])) 15 {*movdf_insn} (nil))
(insn 257 256 258 10 e_cosh.c:956 (use (reg/i:DF 2 d2)) -1 (nil))
(note 258 257 259 10 NOTE_INSN_EPILOGUE_BEG)
;; return d2
(jump_insn 259 258 262 10 e_cosh.c:956 (return) 119 {return_insn} (nil))
This code is not nice.
;; d8 = d4 * d6
;; d8 = d2
;; d2 = d8
;; return d2
The copy to d8 is superfluous and all in all this is just a tail call of
__d_mul which is the ABI-name of muldf3. So the code could be
;; return d4 * d6 // tail-call of __d_mul
because all this runs after peephole2 I had to introduce a second peephole2 in
passes.c like this:
NEXT_PASS (pass_postreload_cse);
NEXT_PASS (pass_gcse2);
NEXT_PASS (pass_split_after_reload);
NEXT_PASS (pass_branch_target_load_optimize1);
NEXT_PASS (pass_thread_prologue_and_epilogue);
NEXT_PASS (pass_rtl_dse2);
NEXT_PASS (pass_stack_adjustments);
NEXT_PASS (pass_peephole2);
NEXT_PASS (pass_if_after_reload);
NEXT_PASS (pass_regrename);
NEXT_PASS (pass_cprop_hardreg);
NEXT_PASS (pass_fast_rtl_dce);
NEXT_PASS (pass_reorder_blocks);
+#ifdef __TRICORE__
+ NEXT_PASS (pass_cprop_hardreg);
+ NEXT_PASS (pass_fast_rtl_dce);
+ NEXT_PASS (pass_peephole2);
+#endif /* __TRICORE__ */
NEXT_PASS (pass_branch_target_load_optimize2);
NEXT_PASS (pass_leaf_regs);
NEXT_PASS (pass_split_before_sched2);
NEXT_PASS (pass_sched2);
NEXT_PASS (pass_stack_regs);
The secon run of DCE then eliminates the superfluous move to/from d8 and the
second peephole 2 maps the CALL/RET seequence to a tail-call.
All this needs life information to be up to date or d8 won't be eliminated and
not all peephole2s find their targets. I must admit that I don't like peephole2
and that I just consider it as a kind of last resort optimization. I very much
prefer passes that run before reload like insn-combine, but in cases like this I
have no clue how to fix the bad code without peep2 and without to patch passes.c
To come back to your question, AFAIR, if the return pattern is too complex (i.e.
PARALLEL with CLOBBERs) pass BBRO won't generate copies of the exit block. So
the code will have many jumps to a more or less trivial epilogue.
My original post, however, addresses the first, original peephole2 pass that
comes with gcc sources.
Georg
Re: peephole2: dead regs not marked as dead
Georg Lay schrieb: > This code is not nice. > > ;; d8 = d4 * d6 > ;; d8 = d2 > ;; d2 = d8 > ;; return d2 this should be ;; d2 = d4 * d6 ;; d8 = d2 ;; d2 = d8 ;; return d2 Georg
Is Ada 2005 Issue AI-0157 implemented correctly in GCC 4.6.0?
This Ada 2012 amendment titled "Calling Unchecked Deallocation is illegal for zero-sized pools" has been implemented in GCC 4.6.0 recently (ada/sem_intr.adb). However, the restriction is enforced even when -gnat2005 (or -gnat95) switched are explicitly passed to gcc. Shouldn't this check only be enforced with the -gnat2012 switch? I discovered this trying to build Adacore's gprbuild_gpl_2010 package. The build fails with GCC 4.6.0 with the message "sinput.adb:808:19: deallocation from empty storage pool" The -gnat05 switch is explicitly used in the gpr settings, so I would expect AI-0157 to not be in effect. Am I wrong? Regards, John
Re: Is Ada 2005 Issue AI-0157 implemented correctly in GCC 4.6.0?
On 10/28/2010 9:37 AM, John Marino wrote: This Ada 2012 amendment titled "Calling Unchecked Deallocation is illegal for zero-sized pools" has been implemented in GCC 4.6.0 recently (ada/sem_intr.adb). However, the restriction is enforced even when -gnat2005 (or -gnat95) switched are explicitly passed to gcc. Shouldn't this check only be enforced with the -gnat2012 switch? I discovered this trying to build Adacore's gprbuild_gpl_2010 package. The build fails with GCC 4.6.0 with the message "sinput.adb:808:19: deallocation from empty storage pool" The -gnat05 switch is explicitly used in the gpr settings, so I would expect AI-0157 to not be in effect. Am I wrong? This is a binding interpretation, which means that it is something that should have been there all along and is reasonable to include in earlier versions, so this change is indeed deliberate and fine. If your code runs afoul of the change, you were doing erroneous things anyway.
Re: Is Ada 2005 Issue AI-0157 implemented correctly in GCC 4.6.0?
Thanks for the explanation, Robert. To be clear, it's code maintained by Adacore that has run afoul of the change. I don't believe gprbuild is part of Adacore's public repository, so I'm not quite sure how I'm supposed to obtain a version of gprbuild that will compile with GCC 4.6.0. This version was released with GNAT GPL 2010 recently, rather than separately, so I'm afraid that I'll need to wait until around July 2011 before the next release! :( Maybe a patch for gprbuild_gpl_2010 can be made available? Regards, John On 28/10/2010 15:47, Robert Dewar wrote: On 10/28/2010 9:37 AM, John Marino wrote: This Ada 2012 amendment titled "Calling Unchecked Deallocation is illegal for zero-sized pools" has been implemented in GCC 4.6.0 recently (ada/sem_intr.adb). However, the restriction is enforced even when -gnat2005 (or -gnat95) switched are explicitly passed to gcc. Shouldn't this check only be enforced with the -gnat2012 switch? I discovered this trying to build Adacore's gprbuild_gpl_2010 package. The build fails with GCC 4.6.0 with the message "sinput.adb:808:19: deallocation from empty storage pool" The -gnat05 switch is explicitly used in the gpr settings, so I would expect AI-0157 to not be in effect. Am I wrong? This is a binding interpretation, which means that it is something that should have been there all along and is reasonable to include in earlier versions, so this change is indeed deliberate and fine. If your code runs afoul of the change, you were doing erroneous things anyway.
Help with reloading FP + offset addressing mode
Hi,
I am doing a port in GCC 4.5.1. For the port
1. there is only (reg + offset) addressing mode only when reg is SP.
Other base registers are not allowed
2. FP cannot be used as a base register. (FP based addressing is done
by copying it into a base register)
In order to take advantage of FP elimination (this will create SP +
offset addressing), what i did the following
1. Created a new register class (address registers + FP) and used this
new class as the BASE_REG_CLASS
2. Defined HARD_REGNO_OK_FOR_BASE_P like the following :
#define HARD_REGNO_OK_FOR_BASE_P(NUM) \
((NUM) < FIRST_PSEUDO_REGISTER \
&& (((reload_completed || reload_in_progress)? 0 : (NUM) == FP_REG) \
|| REGNO_REG_CLASS(NUM) == ADD_REGS))
3. In legitimate_address_p i have the followoing:
if (REGNO (x) == FP_REG)
{
if (strict)
return false;
else
return true;
}
else if (strict)
return STRICT_REG_OK_FOR_BASE_P (REGNO (x));
else
return NONSTRICT_REG_OK_FOR_BASE_P (REGNO (x));
But when FP doesn't get eliminated i will get address of the form
(plus:QI (reg/f:QI 27 as15) (const_int 2))
which gets reloaded by replacing FP with address register, other than
SP. I am guessing this happens because of modified BASE_REG_CLASS. I
haven't confirmed this. So in order to over come this what i have done
is, in legitimize_reload_address i have the following :
if (GET_CODE (*x) == PLUS
&& REG_P (XEXP (*x, 0))
&& REGNO (XEXP (*x, 0)) < FIRST_PSEUDO_REGISTER
&& GET_CODE (XEXP (*x, 1)) == CONST_INT
&& XEXP (*x, 0) == frame_pointer_rtx)
{
/* GCC will by default reload the FP into a BASE_CLASS_REG,
which results in an invalid address. For us, the best
thing to do is move the whole expression to a REG. */
push_reload (*x, NULL_RTX, x, NULL, SPAA_REGS,
mode, VOIDmode,0, 0, opnum, (enum reload_type)type);
return 1;
}
Does my logic makes sense? Is there any better way to implement this?
With this implementation for the following sequence :
(insn 9 6 10 2 fun_calls.c:12 (set (reg/f:QI 42)
(mem/f/c/i:QI (plus:QI (reg/f:QI 33 AP)
(const_int -2 [0xfffe])) [0 f+0 S1 A32]))
9 {movqi_op} (nil))
(insn 10 9 11 2 fun_calls.c:12 (set (reg:QI 43)
(const_int 60 [0x3c])) 7 {movqi_op} (nil))
I am getting the following output:
(insn 45 6 47 2 fun_calls.c:12 (set (reg:QI 28 a0)
(const_int 2 [0x2])) 9 {movqi_op} (nil))
(insn 47 45 48 2 fun_calls.c:12 (set (reg:QI 28 a0)
(reg/f:QI 27 as15)) 9 {movqi_op} (nil))
(insn 48 47 49 2 fun_calls.c:12 (set (reg:QI 28 a0)
(plus:QI (reg:QI 28 a0)
(const_int 2 [0x2]))) 14 {addqi3} (expr_list:REG_EQUIV
(plus:QI (reg/f:QI 27 as15)
(const_int 2 [0x2]))
(nil)))
(insn 49 48 10 2 fun_calls.c:12 (set (reg/f:QI 0 g0 [42])
(mem/f/c/i:QI (reg:QI 28 a0) [0 f+0 S1 A32])) 9 {movqi_op} (nil))
insn 45 is redundant. Is this generated because the
legitimize_reload_address is wrong?
Any hints as to why the redundant instruction gets generated?
Regards,
Shafi
Re: Is Ada 2005 Issue AI-0157 implemented correctly in GCC 4.6.0?
> To be clear, it's code maintained by Adacore that has run afoul of the > change. I don't believe gprbuild is part of Adacore's public repository, > so I'm not quite sure how I'm supposed to obtain a version of gprbuild that > will compile with GCC 4.6.0. This version was released with GNAT GPL 2010 > recently, rather than separately, so I'm afraid that I'll need to wait > until around July 2011 before the next release! :( Maybe a patch for > gprbuild_gpl_2010 can be made available? Note that this is getting off topic for this list. gprbuild gpl 2010 is really intended to be built with GNAT GPL 2010, and can't always be compatible with more recent GNAT versions (even if in general it should be). The change here should be trivial to do in the source code, so if you are interested in compiling gprbuild from sources you can always modify the source directly, or you can simply use the prebuilt gprbuild binary (or compile it with GNAT GPL 2010). Arno
Re: peephole2: dead regs not marked as dead
On 10/28/2010 03:10 PM, Georg Lay wrote: Georg Lay schrieb: This code is not nice. ;; d8 = d4 * d6 ;; d8 = d2 ;; d2 = d8 ;; return d2 this should be ;; d2 = d4 * d6 ;; d8 = d2 ;; d2 = d8 ;; return d2 It seems to me that some of your peepholes should instead be implemented using constraints and multiple alternatives (for example the xor one), so that reload and register allocation can do a better job. However I can't tell without looking at the code. Paolo
Fwd: NEW GCC build failure, h...@166030 on native
The important part of the log is: /bin/sh ./libtool --tag=CC --mode=compile /Users/regress/tbox/native/build/./gcc/xgcc -B/Users/regress/tbox/native/build/./gcc/ -B/Users/regress/tbox/objs/powerpc-apple-darwin9.8.0/bin/ -B/Users/regress/tbox/objs/powerpc-apple-darwin9.8.0/lib/ -isystem /Users/regress/tbox/objs/powerpc-apple-darwin9.8.0/include -isystem /Users/regress/tbox/objs/powerpc-apple-darwin9.8.0/sys-include -DHAVE_CONFIG_H -I. -I/Users/regress/tbox/svn-gcc/boehm-gc -I./include -I/Users/regress/tbox/svn-gcc/boehm-gc/include -fexceptions -Iinclude -I././targ-include -I.//libc/include -g -O2 -mtune=generic -c -o allchblk.lo /Users/regress/tbox/svn-gcc/boehm-gc/allchblk.c libtool: compile: /Users/regress/tbox/native/build/./gcc/xgcc -B/Users/regress/tbox/native/build/./gcc/ -B/Users/regress/tbox/objs/powerpc-apple-darwin9.8.0/bin/ -B/Users/regress/tbox/objs/powerpc-apple-darwin9.8.0/lib/ -isystem /Users/regress/tbox/objs/powerpc-apple-darwin9.8.0/include -isystem /Users/regress/tbox/objs/powerpc-apple-darwin9.8.0/sys-include -DHAVE_CONFIG_H -I. -I/Users/regress/tbox/svn-gcc/boehm-gc -I./include -I/Users/regress/tbox/svn-gcc/boehm-gc/include -fexceptions -Iinclude -I././targ-include -I.//libc/include -g -O2 -mtune=generic -c /Users/regress/tbox/svn-gcc/boehm-gc/allchblk.c -fno-common -DPIC -o .libs/allchblk.o /Users/regress/tbox/svn-gcc/boehm-gc/allchblk.c:1:0: error: bad value (generic) for -mtune= switch make[3]: *** [allchblk.lo] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-target-boehm-gc] Error 2 make[1]: *** Waiting for unfinished jobs -- Forwarded message -- From: regress Date: Thu, Oct 28, 2010 at 12:49 PM Subject: NEW GCC build failure, h...@166030 on native To: gcc-regress...@gcc.gnu.org With your recent patch, GCC HEAD revision 166030 had problems on: native: build (NEW build failure) Attached is build output for those targets. The previous build was of revision 166026. Log information for changes since the last build: r166027 | ebotcazou | 2010-10-28 03:32:03 -0700 (Thu, 28 Oct 2010) | 19 lines Changed paths: M /trunk/gcc/ChangeLog M /trunk/gcc/combine.c * combine.c (set_nonzero_bits_and_sign_copies): Use unsigned arithmetics in masking operations. (contains_muldiv): Likewise. (try_combine): Likewise. (find_split_point): Likewise. (combine_simplify_rtx): Likewise. (simplify_if_then_else): Likewise. (simplify_set): Likewise. (expand_compound_operation): Likewise. (expand_field_assignment): Likewise. (make_extraction): Likewise. (extract_left_shift): Likewise. (make_compound_operation): Likewise. (force_to_mode): Likewise. (make_field_assignment): Likewise. (reg_nonzero_bits_for_combine): Likewise. (simplify_shift_const_1): Likewise. (simplify_comparison): Likewise. r166028 | bonzini | 2010-10-28 03:58:48 -0700 (Thu, 28 Oct 2010) | 11 lines Changed paths: M /trunk/boehm-gc/ChangeLog M /trunk/boehm-gc/Makefile.am M /trunk/boehm-gc/Makefile.in M /trunk/boehm-gc/configure M /trunk/boehm-gc/configure.ac M /trunk/boehm-gc/include/Makefile.in 2010-10-28 Paolo Bonzini * configure.ac: Rewrite DGUX check to use GC_CFLAGS, and -O0 check to remove the need for MY_CFLAGS. * Makefile.am: Do not use @...@ substitutions. Use AM_CXXFLAGS, AM_CFLAGS and AM_LDFLAGS instead of redefining LTCOMPILE and LINK. Use "override" to disable -O2 when required. * configure: Regenerate. * Makefile.in: Regenerate. * include/Makefile.in: Regenerate. r166029 | ams | 2010-10-28 05:36:14 -0700 (Thu, 28 Oct 2010) | 7 lines Changed paths: M /trunk/gcc/ChangeLog M /trunk/gcc/config/arm/arm.c 2010-10-28 Andrew Stubbs gcc/ * config/arm/arm.c (const_ok_for_arm): Support 0xXY00XY00 pattern constants in thumb2. r166030 | paolo | 2010-10-28 09:01:05 -0700 (Thu, 28 Oct 2010) | 35 lines Changed paths: M /trunk/libstdc++-v3/ChangeLog M /trunk/libstdc++-v3/include/bits/hashtable.h M /trunk/libstdc++-v3/include/bits/hashtable_policy.h M /trunk/libstdc++-v3/include/bits/unordered_map.h M /trunk/libstdc++-v3/include/debug/unordered_map M /trunk/libstdc++-v3/include/debug/unordered_set M /trunk/libstdc++-v3/include/profile/unordered_map M /trunk/libstdc++-v3/include/profile/unordered_set M /trunk/libstdc++-v3/testsuite/23_containers/unordered_map/insert/array_syntax.cc A /trunk/libstdc++-v3/testsuite/23_containers/unordered_map/insert/array_syntax_move.cc A /trunk/libstdc++-v3/testsuite/23_containers/unordered_map/insert/map_single_move-1.cc A /tr
Re: Fwd: NEW GCC build failure, h...@166030 on native
On 10/29/2010 12:35 AM, Andrew Pinski wrote: The important part of the log is: /bin/sh ./libtool --tag=CC --mode=compile /Users/regress/tbox/native/build/./gcc/xgcc -B/Users/regress/tbox/native/build/./gcc/ -B/Users/regress/tbox/objs/powerpc-apple-darwin9.8.0/bin/ -B/Users/regress/tbox/objs/powerpc-apple-darwin9.8.0/lib/ -isystem /Users/regress/tbox/objs/powerpc-apple-darwin9.8.0/include -isystem /Users/regress/tbox/objs/powerpc-apple-darwin9.8.0/sys-include -DHAVE_CONFIG_H -I. -I/Users/regress/tbox/svn-gcc/boehm-gc -I./include -I/Users/regress/tbox/svn-gcc/boehm-gc/include -fexceptions -Iinclude -I././targ-include -I.//libc/include -g -O2 -mtune=generic -c -o allchblk.lo /Users/regress/tbox/svn-gcc/boehm-gc/allchblk.c libtool: compile: /Users/regress/tbox/native/build/./gcc/xgcc -B/Users/regress/tbox/native/build/./gcc/ -B/Users/regress/tbox/objs/powerpc-apple-darwin9.8.0/bin/ -B/Users/regress/tbox/objs/powerpc-apple-darwin9.8.0/lib/ -isystem /Users/regress/tbox/objs/powerpc-apple-darwin9.8.0/include -isystem /Users/regress/tbox/objs/powerpc-apple-darwin9.8.0/sys-include -DHAVE_CONFIG_H -I. -I/Users/regress/tbox/svn-gcc/boehm-gc -I./include -I/Users/regress/tbox/svn-gcc/boehm-gc/include -fexceptions -Iinclude -I././targ-include -I.//libc/include -g -O2 -mtune=generic -c /Users/regress/tbox/svn-gcc/boehm-gc/allchblk.c -fno-common -DPIC -o .libs/allchblk.o /Users/regress/tbox/svn-gcc/boehm-gc/allchblk.c:1:0: error: bad value (generic) for -mtune= switch Fixed by regenerating configure. Paolo
gcc-4.5-20101028 is now available
Snapshot gcc-4.5-20101028 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20101028/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 166049 You'll find: gcc-4.5-20101028.tar.bz2 Complete GCC (includes all of below) MD5=350b62b7aa24c7a7ac7854c3050c1225 SHA1=8dec04b9a6a1e24fb13e1cbdd84ec969ebe5d913 gcc-core-4.5-20101028.tar.bz2C front end and core compiler MD5=1ac102dcd89066fd336f3dd2e12c3a8e SHA1=2f76defcd3e1a6f4e924fc70037f7701bbae34b9 gcc-ada-4.5-20101028.tar.bz2 Ada front end and runtime MD5=8c533b089a1324b6661e3bc493d2b484 SHA1=99b739eb392e2bcf12549f1f0a10bb25bcd64faa gcc-fortran-4.5-20101028.tar.bz2 Fortran front end and runtime MD5=f4a76508b2e5987a39c05281092d9344 SHA1=d6a16a93a8be64dfd74cd31bcc3744de0df95f3e gcc-g++-4.5-20101028.tar.bz2 C++ front end and runtime MD5=246c914da17f5286fde0dcc5611f0394 SHA1=915850fd203b58855e1d992dfbdcbdd3d76eea0b gcc-java-4.5-20101028.tar.bz2Java front end and runtime MD5=586f3284e0e26cdda8085cc8048b6bc3 SHA1=1ac3ff4e9a05dc93b46276dcfadfcd8b01acf998 gcc-objc-4.5-20101028.tar.bz2Objective-C front end and runtime MD5=9c193ace7c8ad668eeba9553eba5d7a7 SHA1=a034edbeecf9e06fd0e5d5a9e3503a118c820447 gcc-testsuite-4.5-20101028.tar.bz2 The GCC testsuite MD5=eb739145767c4e2478cd5656f70b8445 SHA1=8ddd68f9d8dd41d6a19d99da9d05db1baf363ce6 Diffs from 4.5-20101021 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 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.
simple for loop on g++ 4.4.3
dear linux(or g++) user/programer with c++: my name is eric, when I use most
current g++ 4.3.3 on ubuntu to test 2 simple c++ programs, one have compiler
error,
// formore.cpp -- more looping with for
#include
using namespace std;
const int ArSize = 16; // example of external declaration
int main()
{
double factorials[ArSize];
factorials[1] = factorials[0] = 1.0;
// int i;
for (int i = 2; i < ArSize; i++)
factorials[i] = i * factorials[i-1];
for (i = 0; i < ArSize; i++)
cout << i << "! = " << factorials[i] << endl;
return 0;
}
e...@eric-laptop:~/Documents/c++primerplus/download/ch05$ g++ formore.cpp
formore.cpp: In function int main():
formore.cpp:12: error: name lookup of i changed for ISO for scoping
formore.cpp:12: note: (if you use -fpermissive G++ will accept your code)
--
or even more simpler
#include
using namespace std;
int main () {
for (int i=0; i<5; i++)
cout << "C++ know loops.\n";
cout << i << endl;
return(0);
}
e...@eric-laptop:~$ g++ try.c++
try.c++: In function int main():
try.c++:11: error: name lookup of i changed for ISO for scoping
try.c++:11: note: (if you use -fpermissive G++ will accept your code)
--
the other is OK
---
// bigstep.cpp -- count as directed
#include
int main()
{
using namespace std;
cout << "Enter an integer: ";
int by;
cin >> by;
cout << "Counting by " << by << "s:\n";
for (int i = 0; i < 100; i = i + by)
cout << i << endl;
return 0;
}
---
e...@eric-laptop:~/Documents/c++primerplus/download/ch05$ g++ bigstep.cpp
e...@eric-laptop:~/Documents/c++primerplus/download/ch05$ ./a.out
you can see both programs, their for loop are very similar(or the same)
for (int i=0
but why first , and second programs can not compile
but
the third one is OK
?
please advice, thanks in advance your effort and time, fs...@luxmail.com
Re: simple for loop on g++ 4.4.3
On 28 October 2010 23:41, eric lin wrote: > you can see both programs, their for loop are very similar(or the same) > for (int i=0 > but why first , and second programs can not compile > but > the third one is OK > ? This mailing list is for development of gcc, not help using it, please send these sort of questions to gcc-help mailing list, as described at http://gcc.gnu.org/lists.html Please take any further questions to the gcc-help mailing list. Your first and second examples are not valid C++, the error tells you why. The variable 'i' is declared in the for-loop and is not in scope after the loop.
A Framework for GCC Plug-ins
One of my research projects for the past few months has been a framework for writing GCC instrumentation plug-ins called InterAspect. I am releasing the project today, and since there is a general interest in plug-ins on this list, I wanted to send a quick announcement with a pointer to the web site: http://www.fsl.cs.sunysb.edu/interaspect/ The idea of compiler plug-ins has a lot of potential, which is why I hope this framework can make compiler plug-ins in general more accessible to people who don't have extensive background in GCC's internal workings. All the code for the project is available under the GPLv3. Also, I'll be presenting the project at the International Conference on Runtime Verification 2010, which is next week. Thanks a lot to everybody on the list who helped out with questions while I was working on this. --Justin
Re: define_split
roy rosen writes: > I am trying to use define_split, but it seems to me that I don't > understand how it is used. > It says in the gccint.pdf (which I use as my tutorial (is there > anything better or more up to date?)) Assuming you built gccint.pdf from the gcc sources that you are using for development, then, no, there is nothing better. > that the combiner only uses the > define_split if it doesn't find any define_insn to match. This is not > clear to me: If there is no define_insn to match a pattern in the > combine stage, then how is this pattern there in the first place? The > only way I can think for it to happen is that such a pattern was > created by the combiner itself (but it seems unreasonable to me that > we now want to split what the combiner just combined). Can someone > please explain this to me? The combiner works by combining existing insns into new patterns, and then attempting to recognize the new patterns (that is why it is called the combiner--becuse it combines patterns). The combiner combines insns by, essentially, looking for cases like (set (reg N) (AAA)) (... (reg N) ...) and turning them into (... (AAA) ...) Actually it's a lot more complicated but that's the basic idea. So the combiner uses splits by constructing large complex patterns and then seeing if it can split them. If you know that certain code sequences are likely to fit together in some complex way, then you can write a define_split to split that complex pattern into a pair of insns. That said, this is not a very interesting use of splits these days and it could probably be removed without doing any noticeable harm. These days most people just write the complex pattern using define_insn, and then write a define_split (or a define_insn_and_split) which splits up the insn just before register allocation or just before instruction scheduling. Ian
Re: define_split
2010/10/29 Ian Lance Taylor : > roy rosen writes: > >> I am trying to use define_split, but it seems to me that I don't >> understand how it is used. >> It says in the gccint.pdf (which I use as my tutorial (is there >> anything better or more up to date?)) > > Assuming you built gccint.pdf from the gcc sources that you are using > for development, then, no, there is nothing better. > >> that the combiner only uses the >> define_split if it doesn't find any define_insn to match. This is not >> clear to me: If there is no define_insn to match a pattern in the >> combine stage, then how is this pattern there in the first place? The >> only way I can think for it to happen is that such a pattern was >> created by the combiner itself (but it seems unreasonable to me that >> we now want to split what the combiner just combined). Can someone >> please explain this to me? > > The combiner works by combining existing insns into new patterns, and > then attempting to recognize the new patterns (that is why it is called > the combiner--becuse it combines patterns). The combiner combines insns > by, essentially, looking for cases like > (set (reg N) (AAA)) > (... (reg N) ...) > and turning them into > (... (AAA) ...) > Actually it's a lot more complicated but that's the basic idea. > > So the combiner uses splits by constructing large complex patterns and > then seeing if it can split them. If you know that certain code > sequences are likely to fit together in some complex way, then you can > write a define_split to split that complex pattern into a pair of > insns. > > That said, this is not a very interesting use of splits these days and > it could probably be removed without doing any noticeable harm. These > days most people just write the complex pattern using define_insn, and > then write a define_split (or a define_insn_and_split) which splits up > the insn just before register allocation or just before instruction > scheduling. > Now I am confused, How are they split before register allocation or scheduling. We've said that in any case only the combiner does the splitting. And another thing: gccint says that the define_split is used only if there is no define_insn that matches - but you say now that 'people just write the complex pattern using define_insn, and then write a define_split (or a define_insn_and_split) which splits up the insn' so I don't understand: if they write a define_insn then the pattern matches and the split would not be used. I am confused... Also, how do I build gccint from the current sources. Currently I just use something I found in the internet. Thanks, Roy. > Ian >
Re: Help with reloading FP + offset addressing mode
On 29 October 2010 00:06, Joern Rennecke wrote: > Quoting Mohamed Shafi : > >> Hi, >> >> I am doing a port in GCC 4.5.1. For the port >> >> 1. there is only (reg + offset) addressing mode only when reg is SP. >> Other base registers are not allowed >> 2. FP cannot be used as a base register. (FP based addressing is done >> by copying it into a base register) >> In order to take advantage of FP elimination (this will create SP + >> offset addressing), what i did the following >> >> 1. Created a new register class (address registers + FP) and used this >> new class as the BASE_REG_CLASS > > Stop right there. You need to distinguish between FRAME_POINTER_REGNUM > and HARD_FRAME_POINTER_REGNUM. > From the description given in the internals, i am not able to understand why you suggested this. Could you please explain this? Shafi
Benchmarks for Pointer Analysis
Hi, We are implementing a new context-sensitive algorithm for pointer analysis in GCC-4.5.0. Can anyone please suggest some good benchmarks for testing it ? Thanks, Swaroop.
