Re: abs insn with QI and HI mode
Ying Yi wrote: The generated codes do the following operations: 1) extend variable a_HI (HImode) to temp variable SImode, and do abs operation with SImode operators. I find the gimple intermedia represention as shown below: abs is a standard library function that takes an int as an argument. So if you call abs(), then gcc must convert the argument to type int before generating code for the abs. To get your special char/short abs instructions, we need one of two things 1) Optimization support to recognize a sign-extend followed by an abs, where the target has an abs instruction that operates on the pre-extended value. We can then optimize away the sign extend instruction. This optimization support apparently does not exist at the moment, perhaps because no one has needed it before. 2) Alternative abs function calls that accept short/char. We already have abs (int), labs (long), llabs(long long), fabs (double), fabsf (float) and fabsl (long double). -- Jim Wilson, GNU Tools Support, http://www.specifix.com
gcc-4.1-20070709 is now available
Snapshot gcc-4.1-20070709 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070709/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 126497 You'll find: gcc-4.1-20070709.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20070709.tar.bz2 C front end and core compiler gcc-ada-4.1-20070709.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20070709.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20070709.tar.bz2 C++ front end and runtime gcc-java-4.1-20070709.tar.bz2 Java front end and runtime gcc-objc-4.1-20070709.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20070709.tar.bz2The GCC testsuite Diffs from 4.1-20070702 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 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: Fixing jumps reachability after block reordering
Gregory B. Prokopski wrote:
I reorder the basic blocks in passes.c, right after compute_alignmnets ().
I added a call to shorten_branches(NULL_RTX) right after my BB reordering,
but it didn't change a thing, and I am still getting as errors:
shorten_branches does this:
/* Compute initial lengths, addresses, and varying flags for each
insn. */
for (insn_current_address = 0, insn = first;
insn != 0;
insn_current_address += insn_lengths[uid], insn = NEXT_INSN (insn))
{ ... }
where FIRST is the argument, which means that shorten_branches(NULL_RTX)
will do nothing, which is exactly what you discovered. Try calling it
correctly with a start instruction. If you grep for it, you will see
that the main call to it is
shorten_branches (get_insns ());
which runs it on the entire function. This is probably what you want.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: no_new_pseudos
On Mon, Jul 09, 2007 at 05:26:00PM -0400, Paolo Bonzini wrote: > > >"Joe can open the door during the meeting" could mean "Joe is able to > >open the door (e.g., he has the keys)" or "from time to time, Joe will > >open the door during the meeting (e.g., it has been known to happen)." > > > >But I agree that it doesn't seem to be used that way in gcc. > > And in compilers in general (e.g. may-alias). I think that it is not worth worrying about, and apologize for contributing to the noise. It is rare that the usage is confusing, because the reader can tell from context which is meant in almost all cases.
Re: no_new_pseudos
Bernd Schmidt <[EMAIL PROTECTED]> writes: > Daniel Jacobowitz wrote: > > Am I the only one who completely fails to see the point of the > > spelling change? I realize that you have said you find negative > > predicates confusing - I don't, but I do find changing predicates > > confusing. I applaud cleaning up the definition and/or replacing it > > with a macro, and I'd applaud adding some extra internals > > documentation about it, but I think the fact that it's been called > > no_new_pseudos for so long suggests that we should just leave it > > called that if we want a predicate that means the same thing. > > I agree. This is unnecessary churn that'll do nothing except make it > harder to move patches between branches. I disagree, as I've stated several times. And we're only talking about 154 occurrences here across the whole compiler, and this is not code which changes frequently. I believe we can tolerate that amount of churn. Ian
Reply Immediately
Peace be unto you my good friend. I am the only surviving child of the Abdullah Öcalan.The leader of the Kurdistan Workers Party (PKK).My father actively fought for the liberation and unification of our people (The Kurds) under one sovereign nation which earned him the support of many and being branded a rebel by others. He amassed a lot of money garnered from supporters and sympathisers alike from which he kept quite a lot for his family's use. http://en.wikipedia.org/wiki/Abdullah_%C3%96calan Before his sudden arrest in 1999,he confided in me the whereabouts of this money and instructed me to find means of investing the funds far away from the reach of the Turkish government who have frozen most of the a ccounts and assets of the PKK.I need t o , more than ever invest this money for the benefit of my three year old son Hassan.He is all that is left of the Öcalan family.A few months ago I was diagnosed with cancer and was told by doctors that I have not long to live. My dear father will not be released by the Turkish government any time soon. All I ask of you is to assist in the transfer and investment of the funds in a neutral country on behalf of Hassan, my son till he is of age. Please read and respond to : [EMAIL PROTECTED] Thanks, Hamad Ocalan.
Reply Immediately
Peace be unto you my good friend. I am the only surviving child of the Abdullah Öcalan.The leader of the Kurdistan Workers Party (PKK).My father actively fought for the liberation and unification of our people (The Kurds) under one sovereign nation which earned him the support of many and being branded a rebel by others. He amassed a lot of money garnered from supporters and sympathisers alike from which he kept quite a lot for his family's use. http://en.wikipedia.org/wiki/Abdullah_%C3%96calan Before his sudden arrest in 1999,he confided in me the whereabouts of this money and instructed me to find means of investing the funds far away from the reach of the Turkish government who have frozen most of the a ccounts and assets of the PKK.I need t o , more than ever invest this money for the benefit of my three year old son Hassan.He is all that is left of the Öcalan family.A few months ago I was diagnosed with cancer and was told by doctors that I have not long to live. My dear father will not be released by the Turkish government any time soon. All I ask of you is to assist in the transfer and investment of the funds in a neutral country on behalf of Hassan, my son till he is of age. Please read and respond to : [EMAIL PROTECTED] Thanks, Hamad Ocalan.
Re: RFC: GIMPLE tuples. Design and implementation proposal
On 7/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >In a message dated 7/7/2007 4:04:01 A.M. Pacific Daylight Time, Rob1weld writes: >This page http://deputy.cs.berkeley.edu/ has a link to this document http://hal.cs.berkeley.edu/cil/ >which describes a means to obtain three-address code here http://hal.cs.berkeley.edu/cil/ext.html#toc24 . >>2007/7/08, Diego Novillo <[EMAIL PROTECTED] (mailto:[EMAIL PROTECTED]) >: >>Any specific reasons why we should? Better memory savings? Faster >>processing? It's not clear from your message what the advantages would >>be (ignoring the fact that their implementation language is completely >>different). You haven't explained what advantages CIL's IR has over GIMPLE. I can't tell, but you may be under the impression GIMPLE is something in the future. It is not. Our IR is already GIMPLE, and a three address code simplified form of C. We are simply talking about changing the underlying datastructures that store it. Hint: CIL's IR is almost exactly GIMPLE with alpha renaming over multiple units. --Dan
Re: no_new_pseudos
"Joe can open the door during the meeting" could mean "Joe is able to open the door (e.g., he has the keys)" or "from time to time, Joe will open the door during the meeting (e.g., it has been known to happen)." But I agree that it doesn't seem to be used that way in gcc. And in compilers in general (e.g. may-alias). Paolo
Re: no_new_pseudos
Eric Botcazou <[EMAIL PROTECTED]> writes:
> tree-ssa-loop-im.c:may_move_till (tree ref, tree *index, void *data)
> tree-ssa-loop-prefetch.c:may_use_storent_in_loop_p (struct loop *loop)
So there are some existing cases of asking permission using "may".
Joe Buck <[EMAIL PROTECTED]> writes:
> "May" can either mean that someone has permission to do something ("is
> allowed to"), or
> that it is possible that something could happen ("might"). Example:
>
> "Bill may leave before the meeting is over." could mean
>
> Bill has permission to leave before the meeting is over.
>
> or
>
> It is possible that Bill will leave before the meeting is over.
True, but essentially the same ambiguity is present for "can."
"Joe can open the door during the meeting" could mean "Joe is able to
open the door (e.g., he has the keys)" or "from time to time, Joe will
open the door during the meeting (e.g., it has been known to happen)."
But I agree that it doesn't seem to be used that way in gcc.
Ian
Re: no_new_pseudos
Eric Botcazou <[EMAIL PROTECTED]> writes:
> tree-ssa-loop-im.c:may_move_till (tree ref, tree *index, void *data)
> tree-ssa-loop-prefetch.c:may_use_storent_in_loop_p (struct loop *loop)
So there are some existing cases of asking permission using "may".
Joe Buck <[EMAIL PROTECTED]> writes:
> "May" can either mean that someone has permission to do something ("is
> allowed to"), or
> that it is possible that something could happen ("might"). Example:
>
> "Bill may leave before the meeting is over." could mean
>
> Bill has permission to leave before the meeting is over.
>
> or
>
> It is possible that Bill will leave before the meeting is over.
True, but essentially the same ambiguity is present for "can."
"Joe can open the door during the meeting" could mean "Joe is able to
open the door (e.g., he has the keys)" or "from time to time, Joe will
open the door during the meeting (e.g., it has been known to happen)."
But I agree that it doesn't seem to be used that way in gcc.
Ian
Re: AMD64 ABI compatibility
Yea, __attribute__ should be the way to go - however, I have not found any attribute like msabi or so. It still needs to be implemented in the compiler. Most of the ia32 attributes are ignored anyway. On Jul 9, 2007, at 12:55 , H.J. Lu wrote: On Mon, Jul 09, 2007 at 12:48:10PM -0700, Nicolas Alt wrote: Hi! On the AMD64 / x86-64Bit architecture, some arguments of a functions are passed using registers, but there seem to be two different conventions out there. The standard ABI uses 6 registers, but Microsoft compilers use only 4. Because of that, code compiled with gcc cannot call code compiled with a MS compiler without an ugly wrapper. Have there been any efforts to make gcc do function calls the MS way? I guess this would be an important feature for mingw on AMD64. Gcc supports several different ABIs via __attribute__ in the same source file for ia32. I don't see why it shouldn't work on x86-64. H.J.
Re: AMD64 ABI compatibility
Thanks for your reply. The gcc compiler uses %rdi, %rsi, %rdx, %rcx with -mregparm=4, but MS uses %rcx, %rdx, %r8, %r9, so that won't be enough. Also MS requires some space on the stack to be reserved for the 4 regs. Someone has written a wrapper: http://people.freebsd.org/~wpaul/winx64_wrap.S On Jul 9, 2007, at 12:58 , Dave Korn wrote: On 09 July 2007 20:48, Nicolas Alt wrote: Hi! On the AMD64 / x86-64Bit architecture, some arguments of a functions are passed using registers, but there seem to be two different conventions out there. The standard ABI uses 6 registers, but Microsoft compilers use only 4. Because of that, code compiled with gcc cannot call code compiled with a MS compiler without an ugly wrapper. Have there been any efforts to make gcc do function calls the MS way? I guess this would be an important feature for mingw on AMD64. Does -mregparm=4 do what you want? cheers, DaveK -- Can't think of a witty .sigline today
RE: AMD64 ABI compatibility
On 09 July 2007 20:48, Nicolas Alt wrote: > Hi! > > On the AMD64 / x86-64Bit architecture, some arguments of a functions > are passed using registers, but there seem to be two different > conventions out there. The standard ABI uses 6 registers, but > Microsoft compilers use only 4. Because of that, code compiled with > gcc cannot call code compiled with a MS compiler without an ugly > wrapper. > > Have there been any efforts to make gcc do function calls the MS way? > I guess this would be an important feature for mingw on AMD64. Does -mregparm=4 do what you want? cheers, DaveK -- Can't think of a witty .sigline today
Re: AMD64 ABI compatibility
On Mon, Jul 09, 2007 at 12:48:10PM -0700, Nicolas Alt wrote: > Hi! > > On the AMD64 / x86-64Bit architecture, some arguments of a functions > are passed using registers, but there seem to be two different > conventions out there. The standard ABI uses 6 registers, but > Microsoft compilers use only 4. Because of that, code compiled with > gcc cannot call code compiled with a MS compiler without an ugly > wrapper. > > Have there been any efforts to make gcc do function calls the MS way? > I guess this would be an important feature for mingw on AMD64. Gcc supports several different ABIs via __attribute__ in the same source file for ia32. I don't see why it shouldn't work on x86-64. H.J.
AMD64 ABI compatibility
Hi! On the AMD64 / x86-64Bit architecture, some arguments of a functions are passed using registers, but there seem to be two different conventions out there. The standard ABI uses 6 registers, but Microsoft compilers use only 4. Because of that, code compiled with gcc cannot call code compiled with a MS compiler without an ugly wrapper. Have there been any efforts to make gcc do function calls the MS way? I guess this would be an important feature for mingw on AMD64. Thanks, Nicolas
Re: Uncatchable exceptions on some systems.
On Jul 9, 2007, at 2:22 PM, David Daney wrote: Joshua ChaitinPollak wrote: On Jul 9, 2007, at 1:43 PM, David Daney wrote: You don't say what version of uclibc you are using. The last time I checked, exception handling on uClibc was foobar. I am not sure if it is true for the versions you are using. There may be patches floating around that make things work (I know I posted some a while back.) David Daney. I'm using 0.9.28. I didn't realize uclibc could affect this. Can you recommend a version where exceptions work? The problems are in GCC not uClibc. See: http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00815.html That was just a prototype patch and it has been a while since I tried it so I don't know if it is still sufficient. Basically you need to disable -Dinhibit_libc and have the proper dwarf2 exception handling code built into libgcc. In some cases there are problems getting the proper libraries linked so that dl_iterate_pheader (sp?) is resolved in uClibc. David Daney I was able to resolve this problem by recompiling gcc with "--enable- sjlj-exceptions --enable-__cxa_atexit" I'm not sure which (or both) are needed, but they solved my problem. Thanks to David for pointing me in the right direction, -Josh -- Joshua ChaitinPollak Software Engineer Kiva Systems
Re: no_new_pseudos
On Mon, Jul 09, 2007 at 11:54:39AM -0700, Ian Lance Taylor wrote:
> Kenneth Zadeck <[EMAIL PROTECTED]> writes:
>
> > Ian Lance Taylor wrote:
> > > Eric Botcazou <[EMAIL PROTECTED]> writes:
> > >
> > >
> > >>> Note that I spent less time writing this patch than I did replying to
> > >>> the e-mail messages on this thread.
> > >>>
> > >> You're probably going to hit the roof :-) but could you rename the
> > >> predicate
> > >> to can_create_pseudo_p? "may" is somewhat ambiguous for non-native
> > >> speakers.
> > >>
> > >
> > > Shouldn't we see this as a teachable moment for correct English
> > > grammar?
> > >
> > > Ian
> > >
> > you are being mean.
>
> In truth I'm not sure where the ambiguity is. But I admit that I am
> not a non-native speaker.
"May" can either mean that someone has permission to do something ("is
allowed to"), or
that it is possible that something could happen ("might"). Example:
"Bill may leave before the meeting is over." could mean
Bill has permission to leave before the meeting is over.
or
It is possible that Bill will leave before the meeting is over.
Re: no_new_pseudos
> Shouldn't we see this as a teachable moment for correct English > grammar? That would be overloading the predicate. :-) More seriously: [EMAIL PROTECTED]:~/svn/gcc/gcc> grep "^may_" *.c fold-const.c:may_negate_without_overflow_p (tree t) haifa-sched.c:may_trap_exp (rtx x, int is_store) loop-invariant.c:may_assign_reg_p (rtx x) loop-unswitch.c:may_unswitch_on (basic_block bb, struct loop *loop, rtx *cinsn) matrix-reorg.c:may_flatten_matrices_1 (tree stmt) matrix-reorg.c:may_flatten_matrices (struct cgraph_node *node) rtlanal.c:may_trap_p_1 (rtx x, unsigned flags) rtlanal.c:may_trap_p (rtx x) rtlanal.c:may_trap_after_code_motion_p (rtx x) rtlanal.c:may_trap_or_fault_p (rtx x) tree-predcom.c:may_reassociate_p (tree type, enum tree_code code) tree-ssa-alias.c:may_alias_p (tree ptr, HOST_WIDE_INT mem_alias_set, tree-ssa-alias.c:may_be_aliased (tree var) tree-ssa-copy.c:may_propagate_copy (tree dest, tree orig) tree-ssa-copy.c:may_propagate_copy_into_asm (tree dest) tree-ssa-loop-im.c:may_move_till (tree ref, tree *index, void *data) tree-ssa-loop-ivopts.c:may_be_unaligned_p (tree ref) tree-ssa-loop-ivopts.c:may_be_nonaddressable_p (tree expr) tree-ssa-loop-ivopts.c:may_eliminate_iv (struct ivopts_data *data, tree-ssa-loop-prefetch.c:may_use_storent_in_loop_p (struct loop *loop) [EMAIL PROTECTED]:~/svn/gcc/gcc> grep "^can_" *.c bt-load.c:can_move_up (basic_block bb, rtx insn, int n_insns) cfganal.c:can_fallthru (basic_block src, basic_block target) cfghooks.c:can_remove_branch_p (edge e) cfghooks.c:can_merge_blocks_p (basic_block bb1, basic_block bb2) cfghooks.c:can_duplicate_block_p (basic_block bb) cfglayout.c:can_copy_bbs_p (basic_block *bbs, unsigned n) cfgloopmanip.c:can_duplicate_loop_p (struct loop *loop) cfgrtl.c:can_delete_note_p (rtx note) cfgrtl.c:can_delete_label_p (rtx label) combine.c:can_combine_p (rtx insn, rtx i3, rtx pred ATTRIBUTE_UNUSED, rtx succ, combine.c:can_change_dest_mode (rtx x, int added_sets, enum machine_mode mode) except.c:can_throw_internal_1 (int region_number, bool is_resx) except.c:can_throw_internal (rtx insn) except.c:can_throw_external_1 (int region_number, bool is_resx) except.c:can_throw_external (rtx insn) expr.c:can_move_by_pieces (unsigned HOST_WIDE_INT len, expr.c:can_store_by_pieces (unsigned HOST_WIDE_INT len, fwprop.c:can_simplify_addr (rtx addr) gcse.c:can_copy_p (enum machine_mode mode) gcse.c:can_assign_to_reg_p (rtx x) lambda-code.c:can_put_in_inner_loop (struct loop *inner, tree stmt) lambda-code.c:can_put_after_inner_loop (struct loop *loop, tree stmt) lambda-code.c:can_convert_to_perfect_nest (struct loop *loop) lower-subreg.c:can_decompose_p (rtx x) matrix-reorg.c:can_calculate_expr_before_stmt (tree expr, sbitmap visited) optabs.c:can_compare_p (enum rtx_code code, enum machine_mode mode, optabs.c:can_conditionally_move_p (enum machine_mode mode) optabs.c:can_extend_p (enum machine_mode to_mode, enum machine_mode from_mode, optabs.c:can_fix_p (enum machine_mode fixmode, enum machine_mode fltmode, optabs.c:can_float_p (enum machine_mode fltmode, enum machine_mode fixmode, predict.c:can_predict_insn_p (rtx insn) reload.c:can_reload_into (rtx in, int regno, enum machine_mode mode) sched-rgn.c:can_schedule_ready_p (rtx insn) tree-data-ref.c:can_use_analyze_subscript_affine_affine (tree *chrec_a, tree *chrec_b) tree-sra.c:can_completely_scalarize_p (struct sra_elt *elt) tree-ssa-forwprop.c:can_propagate_from (tree def_stmt) tree-ssa-loop-manip.c:can_unroll_loop_p (struct loop *loop, unsigned factor, tree-ssa-pre.c:can_value_number_call (tree stmt) tree-ssa-pre.c:can_value_number_operation (tree op) tree-ssa-pre.c:can_PRE_operation (tree op) -- Eric Botcazou
Re: no_new_pseudos
Kenneth Zadeck <[EMAIL PROTECTED]> writes: > Ian Lance Taylor wrote: > > Eric Botcazou <[EMAIL PROTECTED]> writes: > > > > > >>> Note that I spent less time writing this patch than I did replying to > >>> the e-mail messages on this thread. > >>> > >> You're probably going to hit the roof :-) but could you rename the > >> predicate > >> to can_create_pseudo_p? "may" is somewhat ambiguous for non-native > >> speakers. > >> > > > > Shouldn't we see this as a teachable moment for correct English > > grammar? > > > > Ian > > > you are being mean. In truth I'm not sure where the ambiguity is. But I admit that I am not a non-native speaker. Ian
Re: no_new_pseudos
On Mon, Jul 09, 2007 at 02:54:49PM -0400, Richard Kenner wrote: > > Am I the only one who completely fails to see the point of the > > spelling change? I realize that you have said you find negative > > predicates confusing - I don't, but I do find changing predicates > > confusing. I applaud cleaning up the definition and/or replacing it > > with a macro, and I'd applaud adding some extra internals > > documentation about it, but I think the fact that it's been called > > no_new_pseudos for so long suggests that we should just leave it > > called that if we want a predicate that means the same thing. > > The reason to change it is that no_new_pseudos has been misused in the > past to both refer to what it's supposed to mean and to talk about > specific points in the compilation. If we pick a new name (I don't think > anybody cares about the negative or positive distinction) we avoid > perpetuating that history. Now that Ian's accepted the only point in real dispute (that the name should refer to the concept that pseudos can or cannot be produced, not to the phase that the compiler is in), how about letting him pick the name, check in the patch, and kill this thread?
Re: no_new_pseudos
Alexandre Oliva <[EMAIL PROTECTED]> writes: > > Note that I spent less time writing this patch than I did replying to > > the e-mail messages on this thread. > > Yes, it's frustrating, but my experience has been that getting > consensus is generally much more difficult than implementing an > agreed-upon solution :-( I apologize for prolonging the thread, but I never understood what you were asking for. That's why it would have been overall less time to write the patch. Code counts far more than discussion. Ian
Re: no_new_pseudos
Daniel Jacobowitz wrote: Am I the only one who completely fails to see the point of the spelling change? I realize that you have said you find negative predicates confusing - I don't, but I do find changing predicates confusing. I applaud cleaning up the definition and/or replacing it with a macro, and I'd applaud adding some extra internals documentation about it, but I think the fact that it's been called no_new_pseudos for so long suggests that we should just leave it called that if we want a predicate that means the same thing. I agree. This is unnecessary churn that'll do nothing except make it harder to move patches between branches. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
Re: no_new_pseudos
> Am I the only one who completely fails to see the point of the > spelling change? I realize that you have said you find negative > predicates confusing - I don't, but I do find changing predicates > confusing. I applaud cleaning up the definition and/or replacing it > with a macro, and I'd applaud adding some extra internals > documentation about it, but I think the fact that it's been called > no_new_pseudos for so long suggests that we should just leave it > called that if we want a predicate that means the same thing. The reason to change it is that no_new_pseudos has been misused in the past to both refer to what it's supposed to mean and to talk about specific points in the compilation. If we pick a new name (I don't think anybody cares about the negative or positive distinction) we avoid perpetuating that history.
Re: no_new_pseudos
Am I the only one who completely fails to see the point of the spelling change? I realize that you have said you find negative predicates confusing - I don't, but I do find changing predicates confusing. I applaud cleaning up the definition and/or replacing it with a macro, and I'd applaud adding some extra internals documentation about it, but I think the fact that it's been called no_new_pseudos for so long suggests that we should just leave it called that if we want a predicate that means the same thing. -- Daniel Jacobowitz CodeSourcery
Re: no_new_pseudos
Ian Lance Taylor wrote: > Eric Botcazou <[EMAIL PROTECTED]> writes: > > >>> Note that I spent less time writing this patch than I did replying to >>> the e-mail messages on this thread. >>> >> You're probably going to hit the roof :-) but could you rename the predicate >> to can_create_pseudo_p? "may" is somewhat ambiguous for non-native speakers. >> > > Shouldn't we see this as a teachable moment for correct English > grammar? > > Ian > you are being mean.
Re: no_new_pseudos
Eric Botcazou <[EMAIL PROTECTED]> writes: > > Note that I spent less time writing this patch than I did replying to > > the e-mail messages on this thread. > > You're probably going to hit the roof :-) but could you rename the predicate > to can_create_pseudo_p? "may" is somewhat ambiguous for non-native speakers. Shouldn't we see this as a teachable moment for correct English grammar? Ian
Re: no_new_pseudos
On Jul 9, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > Alexandre Oliva <[EMAIL PROTECTED]> writes: >> On Jul 9, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: >> >> > Or tell us how you think my patch should be changed. >> >> #define no_new_pseudos (reload_in_progress || reload_completed) >> >> if you want to reword it into a functional macro without a negative, >> then it would take modifying back-ends as well. If so, I guess >> s,no_new_pseudos,can_gen_reg_rtx (),g or can_gen_new_pseudos() would >> do. > OK, what do you think of this patch? Looks good to me, thanks. > Note that I spent less time writing this patch than I did replying to > the e-mail messages on this thread. Yes, it's frustrating, but my experience has been that getting consensus is generally much more difficult than implementing an agreed-upon solution :-( -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
RE: no_new_pseudos
On 09 July 2007 19:24, Eric Botcazou wrote: >> Note that I spent less time writing this patch than I did replying to >> the e-mail messages on this thread. > > You're probably going to hit the roof :-) but could you rename the predicate > to can_create_pseudo_p? "may" is somewhat ambiguous for non-native > speakers. Either way round, I think this patch is the right thing to do. cheers, DaveK -- Can't think of a witty .sigline today
Re: no_new_pseudos
On Jul 9, 2007, at 11:04 AM, Ian Lance Taylor wrote: OK, what do you think of this patch? In hopes of ending this thread, I like this color of red... :-)
Re: no_new_pseudos
> We've moved past that option, now we're arguing about using > regalloc_started_p (). I'm against that. Why are we hardwiring that as the point at which no new pseudos can be created? It seems right for now, but suppose we later have some mechanism for doing regalloc "on the fly"? If you want to know whether you can safely allocate pseudos at a certain point in time, it would seem to me to be most straightforward to do so by interrogating something like "can_allocate_pseudos_now_p".
Re: Uncatchable exceptions on some systems.
Joshua ChaitinPollak wrote: On Jul 9, 2007, at 1:43 PM, David Daney wrote: You don't say what version of uclibc you are using. The last time I checked, exception handling on uClibc was foobar. I am not sure if it is true for the versions you are using. There may be patches floating around that make things work (I know I posted some a while back.) David Daney. I'm using 0.9.28. I didn't realize uclibc could affect this. Can you recommend a version where exceptions work? The problems are in GCC not uClibc. See: http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00815.html That was just a prototype patch and it has been a while since I tried it so I don't know if it is still sufficient. Basically you need to disable -Dinhibit_libc and have the proper dwarf2 exception handling code built into libgcc. In some cases there are problems getting the proper libraries linked so that dl_iterate_pheader (sp?) is resolved in uClibc. David Daney
Re: no_new_pseudos
> Note that I spent less time writing this patch than I did replying to > the e-mail messages on this thread. You're probably going to hit the roof :-) but could you rename the predicate to can_create_pseudo_p? "may" is somewhat ambiguous for non-native speakers. -- Eric Botcazou
Re: Uncatchable exceptions on some systems.
On Jul 9, 2007, at 1:43 PM, David Daney wrote: You don't say what version of uclibc you are using. The last time I checked, exception handling on uClibc was foobar. I am not sure if it is true for the versions you are using. There may be patches floating around that make things work (I know I posted some a while back.) David Daney. I'm using 0.9.28. I didn't realize uclibc could affect this. Can you recommend a version where exceptions work? -- Joshua ChaitinPollak Software Engineer Kiva Systems
Re: no_new_pseudos
> The bad abstraction was causing quirks in *when* no_new_pseudos was set > to 1. But no_new_pseudos is a good abstraction in itself, people are > arguing on whether it is a better abstraction as "reload_in_progress || > reload_completed". I argue that because both have historically been misused, the right abstraction to answer the question "can I allocate a pseudo now?" is some new name.
Re: no_new_pseudos
> I am going to argue that it was a bug that we did not allow new pseudos > after flow had ran. And that we should have always allowed pseudos > before the register allocator. Since flow was so broken, we could not, > we added the hack no_new_pseudos get around that problem. Now we are > saying it is a nice abstraction but I am saying this abstraction should > never have happened in the first place. We now have a better compiler > due to the removal of the hack. I don't think that debating whether it's a "bug" or a "feature" is that relevant. The way I look at it is that at the start of compilation, you can clearly create pseudos. At the end of the process (say, while writing assembler), you can't. So there must be some place in the middle where the state of that attribute changes. That point will vary as the compiler changes, hopefully monotonically to the later phases, but perhaps not. My point is that the back end does not need to know the state of the technology and hence that exact position in the compilation .
Re: Uncatchable exceptions on some systems.
Joshua ChaitinPollak wrote:
Hello,
I'm at my wits end. I'm building a C++ application for an embedded
device, but I'm having trouble catching exceptions within the embedded
environment. The exact same code works fine on my regular desktop
environment, with the same version of GCC (4.1.2).
I've been able to boil this down to a single source file and one compile
command:
g++ -fexceptions -frtti -o program program.cpp
Here is my program, the output from each environment, along with the
output from 'g++ -v' is below.
Thanks for any help you can give, I'm not even sure how to begin
diagnosing this further, so any hints would be appreciated.
-Josh
// BEGIN EXCEPTION TEST
#include
class test {
public:
test() throw(std::exception);
};
test::test() throw(std::exception) {
throw std::exception();
}
int main() {
try {
test t;
}
catch(std::exception e) {
std::cout << "caught" << std::endl;
}
return 0;
}
// END EXCEPTION TEST
Here is what happens when I run from my embedded environment:
moya exceptionTest # g++ -fexceptions -frtti -o program program.cpp
moya exceptionTest # ./program
terminate called after throwing an instance of 'std::exception'
terminate called recursively
Aborted (core dumped)
moya exceptionTest # g++ -v
Using built-in specs.
Target: i586-gentoo-linux-uclibc
Configured
with: /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure
--prefix=/usr --bindir=/usr/i586-gentoo-linux-uclibc/gcc-bin/4.1.2
--includedir=/usr/lib/gcc/i586-gentoo-linux-uclibc/4.1.2/include
--datadir=/usr/share/gcc-data/i586-gentoo-linux-uclibc/4.1.2
--mandir=/usr/share/gcc-data/i586-gentoo-linux-uclibc/4.1.2/man
--infodir=/usr/share/gcc-data/i586-gentoo-linux-uclibc/4.1.2/info
--with-gxx-include-dir=/usr/lib/gcc/i586-gentoo-linux-uclibc/4.1.2/include/g++-v4
--host=i586-gentoo-linux-uclibc --build=i586-gentoo-linux-uclibc
--disable-altivec --disable-nls --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --disable-multilib --disable-libmudflap
--disable-libssp --disable-libgcj --enable-languages=c,c++ --enable-shared
--enable-threads=posix --disable-__cxa_atexit --enable-target-optspace
--enable-clocale=uclibc
Thread model: posix
gcc version 4.1.2 (Gentoo 4.1.2)
You don't say what version of uclibc you are using.
The last time I checked, exception handling on uClibc was foobar. I am
not sure if it is true for the versions you are using. There may be
patches floating around that make things work (I know I posted some a
while back.)
David Daney.
Uncatchable exceptions on some systems.
Hello,
I'm at my wits end. I'm building a C++ application for an embedded
device, but I'm having trouble catching exceptions within the embedded
environment. The exact same code works fine on my regular desktop
environment, with the same version of GCC (4.1.2).
I've been able to boil this down to a single source file and one compile
command:
g++ -fexceptions -frtti -o program program.cpp
Here is my program, the output from each environment, along with the
output from 'g++ -v' is below.
Thanks for any help you can give, I'm not even sure how to begin
diagnosing this further, so any hints would be appreciated.
-Josh
// BEGIN EXCEPTION TEST
#include
class test {
public:
test() throw(std::exception);
};
test::test() throw(std::exception) {
throw std::exception();
}
int main() {
try {
test t;
}
catch(std::exception e) {
std::cout << "caught" << std::endl;
}
return 0;
}
// END EXCEPTION TEST
Here is what happens when I run from my embedded environment:
moya exceptionTest # g++ -fexceptions -frtti -o program program.cpp
moya exceptionTest # ./program
terminate called after throwing an instance of 'std::exception'
terminate called recursively
Aborted (core dumped)
moya exceptionTest # g++ -v
Using built-in specs.
Target: i586-gentoo-linux-uclibc
Configured
with: /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure
--prefix=/usr --bindir=/usr/i586-gentoo-linux-uclibc/gcc-bin/4.1.2
--includedir=/usr/lib/gcc/i586-gentoo-linux-uclibc/4.1.2/include
--datadir=/usr/share/gcc-data/i586-gentoo-linux-uclibc/4.1.2
--mandir=/usr/share/gcc-data/i586-gentoo-linux-uclibc/4.1.2/man
--infodir=/usr/share/gcc-data/i586-gentoo-linux-uclibc/4.1.2/info
--with-gxx-include-dir=/usr/lib/gcc/i586-gentoo-linux-uclibc/4.1.2/include/g++-v4
--host=i586-gentoo-linux-uclibc --build=i586-gentoo-linux-uclibc
--disable-altivec --disable-nls --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --disable-multilib --disable-libmudflap
--disable-libssp --disable-libgcj --enable-languages=c,c++ --enable-shared
--enable-threads=posix --disable-__cxa_atexit --enable-target-optspace
--enable-clocale=uclibc
Thread model: posix
gcc version 4.1.2 (Gentoo 4.1.2)
Here is what happens when I run from my desktop environment:
[EMAIL PROTECTED]:~/src/exceptionTest$ g++ -fexceptions -frtti -o program
program.cpp
[EMAIL PROTECTED]:~/src/exceptionTest$ ./program
caught
[EMAIL PROTECTED]:~/src/exceptionTest$ g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c
++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --program-suffix=-4.1
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
Re: no_new_pseudos
On Jul 9, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > Or tell us how you think my patch should be changed. #define no_new_pseudos (reload_in_progress || reload_completed) if you want to reword it into a functional macro without a negative, then it would take modifying back-ends as well. If so, I guess s,no_new_pseudos,can_gen_reg_rtx (),g or can_gen_new_pseudos() would do. > I think regalloc_started_p is pretty unambiguous. I agree. But the implementation does not match the name, and the name doesn't match the question the back-ends need answered. > If it mattered, we would make it true after local-alloc starts. At > the moment it doesn't matter. But then, if it mattered for some reason unrelated with the ability to create pseudos, would we have to change all uses in back-ends, or live with the additional restriction the change would amount to? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: no_new_pseudos
On Jul 9, 2007, "Andrew Pinski" <[EMAIL PROTECTED]> wrote: > Since flow was so broken, we > could not, we added the hack no_new_pseudos get around that problem. > Now we are saying it is a nice abstraction but I am saying this > abstraction should never have happened in the first place. You're criticizing the implementation behind the abstraction, not the abstraction per se. I agree with the criticism. That we can fix the implementation without changing the abstraction shows it's a good one. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: no_new_pseudos
On Mon, 2007-07-09 at 09:30 -0700, Ian Lance Taylor wrote: > Paolo Bonzini <[EMAIL PROTECTED]> writes: > > > > I am going to argue that it was a bug that we did not allow new > > > pseudos after flow had ran. And that we should have always allowed > > > pseudos before the register allocator. Since flow was so broken, we > > > could not, we added the hack no_new_pseudos get around that problem. > > > Now we are saying it is a nice abstraction but I am saying this > > > abstraction should never have happened in the first place. We now > > > have a better compiler due to the removal of the hack. > > > > The bad abstraction was causing quirks in *when* no_new_pseudos was > > set to 1. But no_new_pseudos is a good abstraction in itself, people > > are arguing on whether it is a better abstraction as > > "reload_in_progress || reload_completed". > > We've moved past that option, now we're arguing about using > regalloc_started_p (). I'm not sure why, and I think I agree with some earlier posters on this issue. As a back-end author, the question of interest is just: can I call gen_reg_rtx()? or must I make do with existing registers? I don't care about which particular phases this is true or false, I just need to know the answer to that question.
Re: no_new_pseudos
This discussion has gotten far too abstract for me. Alexandre, please write your own patch, and we will approve it or not. Or tell us how you think my patch should be changed. Give us code, not discussion. I have already spent more time writing e-mail messages than I've spent writing the patch. > > Since we have no reason to believe that the backend should not > > create new pseudo-registers before register allocation, > > How about during local or global? These are part of register > allocation, they're not covered by the macro you proposed, but one > might assume they are by looking at the macro name. At which point, > which meaning would be right? I think regalloc_started_p is pretty unambiguous. If it mattered, we would make it true after local-alloc starts. At the moment it doesn't matter. Ian
Re: no_new_pseudos
Paolo Bonzini <[EMAIL PROTECTED]> writes: > > I am going to argue that it was a bug that we did not allow new > > pseudos after flow had ran. And that we should have always allowed > > pseudos before the register allocator. Since flow was so broken, we > > could not, we added the hack no_new_pseudos get around that problem. > > Now we are saying it is a nice abstraction but I am saying this > > abstraction should never have happened in the first place. We now > > have a better compiler due to the removal of the hack. > > The bad abstraction was causing quirks in *when* no_new_pseudos was > set to 1. But no_new_pseudos is a good abstraction in itself, people > are arguing on whether it is a better abstraction as > "reload_in_progress || reload_completed". We've moved past that option, now we're arguing about using regalloc_started_p (). Ian
Re: no_new_pseudos
I am going to argue that it was a bug that we did not allow new pseudos after flow had ran. And that we should have always allowed pseudos before the register allocator. Since flow was so broken, we could not, we added the hack no_new_pseudos get around that problem. Now we are saying it is a nice abstraction but I am saying this abstraction should never have happened in the first place. We now have a better compiler due to the removal of the hack. The bad abstraction was causing quirks in *when* no_new_pseudos was set to 1. But no_new_pseudos is a good abstraction in itself, people are arguing on whether it is a better abstraction as "reload_in_progress || reload_completed". Paolo
Re: no_new_pseudos
On 7/9/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: It's true that, before your patch, one couldn't create new pseudos after flow analysis, and after your patch, one can create them all the way until reload. 'no_new_pseudos' would still mean the same: it's true if it's too late to create new pseudos, and false otherwise. I am going to argue that it was a bug that we did not allow new pseudos after flow had ran. And that we should have always allowed pseudos before the register allocator. Since flow was so broken, we could not, we added the hack no_new_pseudos get around that problem. Now we are saying it is a nice abstraction but I am saying this abstraction should never have happened in the first place. We now have a better compiler due to the removal of the hack. -- Pinski
Re: no_new_pseudos
On Jul 9, 2007, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > Apparently there areplaces, at least in the ppc backend that did not > generate pseudos before reload because of the abstraction that are > now able to generate them. I don't understand what you mean by 'because of the abstraction'. It's true that, before your patch, one couldn't create new pseudos after flow analysis, and after your patch, one can create them all the way until reload. 'no_new_pseudos' would still mean the same: it's true if it's too late to create new pseudos, and false otherwise. That's the power of the abstraction: the internal implementation changes, but the exposed interface still offers the same semantics, and things that rely on the abstraction work regardless of the change. Which doesn't mean 'work exactly the same way'. If the change enables them to work even better, they do. If it constraints them further, then they are constrained. But as long as the semantics of the abstraction is unchanged, things work. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: no_new_pseudos
Richard Kenner wrote: >> just as a small point, at least the ppc does behave differently with my >> patch then without it. Apparently there areplaces, at least in the ppc >> backend that did not generate pseudos before reload because of the >> abstraction that are now able to generate them. >> > > I'm sure that's true. > [09:34] > zadeck_: with your patch, gcc ppc will generate more pseudos for materializing constants and splitting some logical ops [09:34] > which is good [09:34] > instead of trying to do the operations in place with existing registers [09:35] > creating read-write dependencies
Re: no_new_pseudos
> just as a small point, at least the ppc does behave differently with my > patch then without it. Apparently there areplaces, at least in the ppc > backend that did not generate pseudos before reload because of the > abstraction that are now able to generate them. I'm sure that's true.
Re: no_new_pseudos
Richard Kenner wrote: >> Now, it is true that the overspecification of the comment above its >> declaration may have led people to use it for different purposes. >> While some may have used it to test whether new pseudos can be >> created, others may have used it to test whether we're on or past life >> analysis. Whether these will break as we relax the restrictions on >> creation of new pseudos is something that only auditing and testing >> will tell. This is a negative side effect of abstraction overloading. >> > > I see it as an effect of NOT creating an abstraction or, perhaps more > precisely, creating a BAD abstraction. > > What the expanders need to know is "can I create a pseudo now?". This does > translate into a "state of compilation" but that's not the needed > abstraction. What's happened is both that parts of the compiler have used > no_new_pseudos for both its original purpose and as a "state of > compilation" flag and that other parts have used things that are explicitly > a state (e.g., "reload_completed") as a test for whether it's safe to > create new psuedos. This has produced the current mess. > > I think it's simpler if we have some way of answering each question that > some code needs an answer to. If an expanded needs to know "I don't care > where we are in the compilation process, I just need to know if I can > create a pseudo", there should be a way to answer that question. If, for > some reason, there's a direct need to know "are we currently in reload", > there should be a way to determine that. But when we start trying to use > the same test to answer both questions, I feel we'll get into trouble. > just as a small point, at least the ppc does behave differently with my patch then without it. Apparently there areplaces, at least in the ppc backend that did not generate pseudos before reload because of the abstraction that are now able to generate them. I did not do any measurements to see if this effected the generated code in a material way, only that more pseudos were generated. kenny
Re: PTR-PLUS merge into the mainline
Hi, On Fri, 6 Jul 2007, Richard Guenther wrote: > Btw, is there a bug-report about the issue you are facing? Please > let's take this issue there. There's now (32698), I kinda hoped it would be easier to fix. :) bye, Roman
Re: no_new_pseudos
> Now, it is true that the overspecification of the comment above its > declaration may have led people to use it for different purposes. > While some may have used it to test whether new pseudos can be > created, others may have used it to test whether we're on or past life > analysis. Whether these will break as we relax the restrictions on > creation of new pseudos is something that only auditing and testing > will tell. This is a negative side effect of abstraction overloading. I see it as an effect of NOT creating an abstraction or, perhaps more precisely, creating a BAD abstraction. What the expanders need to know is "can I create a pseudo now?". This does translate into a "state of compilation" but that's not the needed abstraction. What's happened is both that parts of the compiler have used no_new_pseudos for both its original purpose and as a "state of compilation" flag and that other parts have used things that are explicitly a state (e.g., "reload_completed") as a test for whether it's safe to create new psuedos. This has produced the current mess. I think it's simpler if we have some way of answering each question that some code needs an answer to. If an expanded needs to know "I don't care where we are in the compilation process, I just need to know if I can create a pseudo", there should be a way to answer that question. If, for some reason, there's a direct need to know "are we currently in reload", there should be a way to determine that. But when we start trying to use the same test to answer both questions, I feel we'll get into trouble.
Re: no_new_pseudos
On Jul 9, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > Alexandre Oliva <[EMAIL PROTECTED]> writes: >> On Jul 8, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: >> >> > But since these aspects of the register allocator are not at all >> > likely to change, wouldn't it be a waste of time to prepare for them >> > now? >> >> Yup. But from that to concluding that we should remove the clear >> abstraction that enables someone to prepare for them right now, that >> is useful, mnemonic, clear in meaning, and currently functional. >> >> Replacing that with some variable that denotes some internal state in >> the middle end and requiring the back end to use it is exposing the >> guts of the middle end to the back end. That's breaking abstraction >> layers. That's bad software engineering in general. > Note that that is exactly what was happening before. no_new_pseudos > denoted internal state in the middle end. In a sense, you're right, and I'd never perceived it that way. Maybe it's because I've always perceived it as something turned towards a users' needs (can I create new pseudos?) rather than as something turned towards internal implementation details (do I need to resize register tables afterwards?) That it served both purposes might or might not be a sign of the bad practice of abstraction overloading. Honestly, I was never even aware of the possibility of resizing the tables once no_new_pseudos was set, or even that such tables existed or had anything to do with this flag. To me, no_new_pseudos was part of the gen_reg_rtx API, used to tell its callers that they needed to work around their hunger for pseudos. This is what I get from gccint: The global variable `no_new_pseudos' can be used to determine if it is unsafe to create new pseudo registers. If this variable is nonzero, then it is unsafe to call `gen_reg_rtx' to allocate a new pseudo. I realize now that the comment before the no_new_pseudos declaration in rtl.h mentions life analysis as the point in which no_new_pseudos is set. This does support the claim that it was there for a different purpose. However, the fact that it can be safely replaced by (reload_in_progress || reload_completed) shows the strength of the abstraction it represents. We could change the internal implementation of the compiler in such a major way as to enable pseudos to be created much later in the game (even if this option is not actually exercised) while having to adjust as simple a point as when/how to set no_new_pseudos. Now, it is true that the overspecification of the comment above its declaration may have led people to use it for different purposes. While some may have used it to test whether new pseudos can be created, others may have used it to test whether we're on or past life analysis. Whether these will break as we relax the restrictions on creation of new pseudos is something that only auditing and testing will tell. This is a negative side effect of abstraction overloading. > But I believe that repurposing is bad because the backends do not and > should not use no_new_pseudos consistently. Consistent usage would > require them to check it far more often than they currently do. That > would be counterproductive and even impossible. Instead, the backends > only check it for the specific routines which may be called during > register allocation. Actually, this is all part of the contract between the middle end and the back end. Even if it's implicit, those "in the know" understand that only a few expanders (movM, addM) and splitters are ever supposed to be called with no_new_pseudos set. That's where it needs to be tested if gen_reg_rtx() needs to be called. Does this mean all of them do? Maybe not. Maybe some are failing to do their part in the API contract and they have never been caught in error. Does this mean they should? Yes, certainly. Does this mean we should extend the contract to cover all expanders? Only if there were good reasons to do so. > Since those are the only backend routines which must check > no_new_pseudos, and those are the only backend routines which do check > no_new_pseudos, I think that trying to reclaim no_new_pseudos as a > generic concept separate from register allocation is inappropriate. Looks like it's never been directly related with register allocation, ever since its introduction in revision 23855, in Nov 25, 1998. But since then it's always been checked by gen_reg_rtx, so its use as a test on whether gen_reg_rtx() can be safely called has historically been supported. Can the same be said of any other suggested meaning for this abstraction? > Since we have no reason to believe that the backend should not > create new pseudo-registers before register allocation, How about during local or global? These are part of register allocation, they're not covered by the macro you proposed, but one might assume they are by looking at the macro name. At which point, whic
Re: no_new_pseudos
> Since we have no reason to believe that the backend should not > create new pseudo-registers before register allocation, and since we > have no reason to believe that after register allocation starts it > will be possible for the backend to create new pseudo-registers, I > believe that you are introducing a layer of abstraction which does > not clarify. Although I agree that that's true, the counterargument is that the predicate that the backends care about is "can I allocate a pseudo here?". What that translates into shouldn't be relevant to them. The fact that backends have translated that predicate into different things (no_new_pseudos vs. reload_completed, e.g.) is exactly the sort of thing that happens when we lose this explicitness and the argument for restoring it. > Since that would be obviously nonsensical, it must not be what I > meant. I must have meant what I said: "it was there to remind people > to call the appropriate functions to resize the register arrays." I don't believe that's correct since much more would have needed to have been done aside from resizing the arrays.
Re: RFC: GIMPLE tuples. Design and implementation proposal
>In a message dated 7/7/2007 4:04:01 A.M. Pacific Daylight Time, Rob1weld writes: >This page http://deputy.cs.berkeley.edu/ has a link to this document http://hal.cs.berkeley.edu/cil/ >which describes a means to obtain three-address code here http://hal.cs.berkeley.edu/cil/ext.html#toc24 . >>2007/7/08, Diego Novillo <[EMAIL PROTECTED] (mailto:[EMAIL PROTECTED]) >: >>Any specific reasons why we should? Better memory savings? Faster >>processing? It's not clear from your message what the advantages would >>be (ignoring the fact that their implementation language is completely >>different). And ignoring that portions of GCC are not written in "C": examples being the use of configure scripts to spit out snippets of "C" to (test for compiler features), use of flex, yacc, the various files generated and then compiled. GCC is not 'just "C"' - probably be more portable if it were ... An example of a project using ML for "Intermediate Representation": _http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir-rep.html_ (http://www.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mlrisc-ir-rep.html) Ocaml: - The acronym CAML originally stood for Categorical Abstract Machine Language. - It has a large standard library that makes it useful for many of the same applications as Python or Perl, as well as robust modular and object-oriented programming constructs that make it applicable for large-scale software engineering. - ML-derived languages are best known for their static type systems and type-inferring compilers. OCaml unifies functional, imperative, and object-oriented programming under an ML-like type system. - OCaml's static type system eliminates a large class of programmer errors that may cause problems at runtime. However, it also forces the programmer to conform to the constraints of the type system, which can require careful thought and close attention. A type-inferring compiler greatly reduces the need for manual type annotations. - OCaml is perhaps most distinguished from other languages with origins in academia by its emphasis on performance. Firstly, its static type system renders runtime type mismatches impossible, and thus obviates the need for runtime type and safety checks that burden the performance of dynamically typed languages, while still guaranteeing runtime safety. - Also the reason that you made mention of, CIL is written in that language. The object (and library) files are completely linkable with "C" code. CIL: - organizes C’s imperative features into expressions, instructions and statements based on the presence and absence of side-effects and control-flow. - Every statement can be annotated with successor and predecessor information. - CIL provides an integrated program representation that can be used with routines that require an AST (e.g. type-based analyses and pretty-printers), as well as with routines that require a CFG (e.g., dataflow analyses). - CIL also supports even lower-level representations (e.g., three-address code). Deputy: - Deputy is implemented using the CIL infrastructure for C program analysis and transformation, and it uses GCC as a back end. - Deputy is a C compiler that is capable of preventing common C programming errors, including out-of-bounds memory accesses as well as many other common type-safety errors. It is designed to work on real-world code, up to and including the Linux kernel itself. - Deputy allows C programmers to provide simple type annotations that describe pointer bounds and other important program invariants. Deputy verifies that your program adheres to these invariants through a combination of compile-time and run-time checking. - Unlike other tools for checking C code, Deputy provides a flexible annotation language that allows you to describe many common programming idioms without changing your data structures. As a result, using Deputy requires less programmer effort than other tools. In fact, code compiled with Deputy can be linked directly with code compiled by other C compilers, so you can choose exactly when and where to use Deputy within your C project. I think you will find that Deputy is like "C" with a few extra comment lines. Of course you do not have to have the advantages of using Deputy. You can simply read about CIL and implement a few of CIL's ideas in "C" and use those in GCC. Deputy with CIL provides both a higher level and a lower level than the current implementation and would provide a "C" compiler that has more checks as opposed to one that always has a few bugs (upon which all the rest of the toolchain is built). Portions of the "C" testsuite that fail are a few years old. You mention "Better memory savings? Faster processing?". If that is all you want then what language do you think we would be using - hint it is not very portable. I respect the fact
