Re: PR 20505
James E Wilson wrote:
Nathan Sidwell wrote:
Being conservative I'd go for my patch on 4.0 and yours (if verified) on
mainline.
I'm fine with that. Have you actually written a patch yet? I don't see
one in the bug report or in gcc-patches.
My mistake. I'd forgotten the post-to-list part :)
Here it is, ok?
nathan
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
2005-04-01 Nathan Sidwell <[EMAIL PROTECTED]>
PR debug/20505
* dwarf2out.c (tree_add_const_value_attribute): Only add if it's
an INT_CST.
Index: dwarf2out.c
===
RCS file: /cvs/gcc/gcc/gcc/dwarf2out.c,v
retrieving revision 1.572
diff -c -3 -p -r1.572 dwarf2out.c
*** dwarf2out.c 19 Mar 2005 03:06:51 - 1.572
--- dwarf2out.c 23 Mar 2005 12:13:23 -
*** tree_add_const_value_attribute (dw_die_r
*** 10156,10181
tree init = DECL_INITIAL (decl);
tree type = TREE_TYPE (decl);
! if (TREE_READONLY (decl) && ! TREE_THIS_VOLATILE (decl) && init
! && initializer_constant_valid_p (init, type) == null_pointer_node)
! /* OK */;
! else
return;
!
! switch (TREE_CODE (type))
! {
! case INTEGER_TYPE:
! if (host_integerp (init, 0))
! add_AT_unsigned (var_die, DW_AT_const_value,
!tree_low_cst (init, 0));
! else
! add_AT_long_long (var_die, DW_AT_const_value,
! TREE_INT_CST_HIGH (init),
! TREE_INT_CST_LOW (init));
! break;
!
! default:;
! }
}
/* Generate a DW_AT_name attribute given some string value to be included as
--- 10156,10177
tree init = DECL_INITIAL (decl);
tree type = TREE_TYPE (decl);
! if (!init)
return;
! if (!TREE_READONLY (decl) || TREE_THIS_VOLATILE (decl))
! return;
! if (TREE_CODE (type) != INTEGER_TYPE)
! return;
! if (TREE_CODE (init) != INTEGER_CST)
! return;
!
! if (host_integerp (init, 0))
! add_AT_unsigned (var_die, DW_AT_const_value,
!tree_low_cst (init, 0));
! else
! add_AT_long_long (var_die, DW_AT_const_value,
! TREE_INT_CST_HIGH (init),
! TREE_INT_CST_LOW (init));
}
/* Generate a DW_AT_name attribute given some string value to be included as
// Copyright (C) 2005 Free Software Foundation, Inc.
// Contributed by Nathan Sidwell 1 Apr 2005 <[EMAIL PROTECTED]>
// { dg-options "-ggdb2" }
// Origin: ivan <[EMAIL PROTECTED]>
// [EMAIL PROTECTED]
// Bug 20505: ICE with -ggdb2
struct b
{
static const int d;
virtual bool IsEmpty() const=0;
int e,c;
};
const int b::d = ((int)(&((b*)1)->c) - 1);
Use Bohem's GC for compiler proper in 4.1?
I know that Bohem's GC is used in the Java runtime for GCC. However, the compiler proper itself can _really_ cramp people's avalible RAM (for those who don't belive me and have Windows w/ DJGPP, change all the memory controls from `auto' to the highest value and just try to compile libiberty/regex.c), so my suggestion is usage of Bohem's GC in the compiler proper itself. Samuel Lauber -- _ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze
Re: Use Bohem's GC for compiler proper in 4.1?
Sam Lauber writes: > I know that Bohem's GC is used in the Java runtime for GCC. > However, the compiler proper itself can _really_ cramp people's > avalible RAM (for those who don't belive me and have Windows w/ > DJGPP, change all the memory controls from `auto' to the highest > value and just try to compile libiberty/regex.c), so my suggestion > is usage of Bohem's GC in the compiler proper itself. Do you have any reason to believe that such a change would reduce memory consumption? Andrew.
Re: Use Bohem's GC for compiler proper in 4.1?
On Fri, 2005-04-01 at 12:43 +0100, Andrew Haley wrote: > Sam Lauber writes: > > I know that Bohem's GC is used in the Java runtime for GCC. > > However, the compiler proper itself can _really_ cramp people's > > avalible RAM (for those who don't belive me and have Windows w/ > > DJGPP, change all the memory controls from `auto' to the highest > > value and just try to compile libiberty/regex.c), so my suggestion > > is usage of Bohem's GC in the compiler proper itself. > > Do you have any reason to believe that such a change would reduce > memory consumption? I should note this is a loaded question, because anyone who has actually tried using boehm's gc with gcc will tell you the memory usage actually increases, not decreases. It's almost as if conservative mark and sweep is not going to work as well as accurate mark and sweep. > > Andrew.
Re: Use Bohem's GC for compiler proper in 4.1?
Daniel Berlin writes: > On Fri, 2005-04-01 at 12:43 +0100, Andrew Haley wrote: > > Sam Lauber writes: > > > I know that Bohem's GC is used in the Java runtime for GCC. > > > However, the compiler proper itself can _really_ cramp people's > > > avalible RAM (for those who don't belive me and have Windows w/ > > > DJGPP, change all the memory controls from `auto' to the highest > > > value and just try to compile libiberty/regex.c), so my suggestion > > > is usage of Bohem's GC in the compiler proper itself. > > > > Do you have any reason to believe that such a change would reduce > > memory consumption? > > I should note this is a loaded question, because anyone who has > actually tried using boehm's gc with gcc will tell you the memory > usage actually increases, not decreases. > > It's almost as if conservative mark and sweep is not going to work > as well as accurate mark and sweep. Astonshing, isn't it? :-) To be fair to the Boehm gc, though: it isn't inherently a conservative collector, but will also do precise gc. Andrew.
Re: Use Bohem's GC for compiler proper in 4.1?
Perhaps then a scheme in which the compiler 1) compresses all tree structures (this would be a good project) 2) after each pass, all internal structures are freed unless doing so would create a dead pointer (maybe an -Om option like -Os but saves compilation memory?) 3) dosen't use memory in general, i.e do things like int i; for (i = 0; i != n_something; i++) putc(getc(fp), ofp); instead of things like pointer_to_something = malloc(n_something * sizeof(int)); fgets(n_something, pointer_to_something, fp); fputs(pointer_to_something, ofp); 4) use less memory-intensive alogrithms and investigate using more memory-efficent repersentations Samuel Lauber > > > > I know that Bohem's GC is used in the Java runtime for GCC. > > > > However, the compiler proper itself can _really_ cramp people's > > > > avalible RAM (for those who don't belive me and have Windows w/ > > > > DJGPP, change all the memory controls from `auto' to the highest > > > > value and just try to compile libiberty/regex.c), so my suggestion > > > > is usage of Bohem's GC in the compiler proper itself. > > > > > > Do you have any reason to believe that such a change would reduce > > > memory consumption? > > > > I should note this is a loaded question, because anyone who has > > actually tried using boehm's gc with gcc will tell you the memory > > usage actually increases, not decreases. > > > > It's almost as if conservative mark and sweep is not going to work > > as well as accurate mark and sweep. > > Astonshing, isn't it? :-) > > To be fair to the Boehm gc, though: it isn't inherently a conservative > collector, but will also do precise gc. > > Andrew. -- _ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze
Re: Use Bohem's GC for compiler proper in 4.1?
On 04/01/2005 07:35 AM, Andrew Haley wrote: [snip] To be fair to the Boehm gc, though: it isn't inherently a conservative collector, but will also do precise gc. Wouldn't this require a GC_descr as defined here: http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc_typedh.txt for each data structure containing a pointer to the heap?
Re: about new_regalloc
Hi, On Thu, 31 Mar 2005, zouq wrote: > in gcc3.4.1,i found rest_of_new_handle_regalloc > why in gcc4.0, it has been removed? It was removed from gcc 4 because it bitrotted and broke on all kinds of code. If you want to see a more recent and more working version look at the new-regalloc-branch. Ciao, Michael.
Re: RFC: #pragma optimization_level
Dale Johannesen <[EMAIL PROTECTED]> writes:
> I've currently got the job of implementing pragma(s) to change
> optimization level in the middle of a file. This has come up a few
> times before,
Would it be possible to make it a function attribute? I would
really like to have
void __attribute__((optimization("Os"))) slow_init_function(void)
{
}
to let slow_init_function be compiled as space efficient as possible.
I think that would be very useful for the Linux kernel at least.
There is already a __init modifier for functions that ought to be
freed after initialization and it would be nice to just add a one
liner to make them smaller too.
In addition letting the compiler do that automatically based
on profile feedback for "cold" functions would be very cool.
-Andi
Re: Use Bohem's GC for compiler proper in 4.1?
On 04/01/2005 08:21 AM, Larry Evans wrote: On 04/01/2005 07:35 AM, Andrew Haley wrote: [snip] To be fair to the Boehm gc, though: it isn't inherently a conservative collector, but will also do precise gc. Wouldn't this require a GC_descr as defined here: http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc_typedh.txt for each data structure containing a pointer to the heap? And even then, it wouldn't be totally precise because the stack would still have to be scanned conservatively to locate heap pointers.
Re: GCC 4.1 bootstrap failed at ia64-*-linux
Giovanni Bajo wrote: James E Wilson <[EMAIL PROTECTED]> wrote: IA64 bootstrap failed at abi_check stage reporting undefined references from libstdc++ (see log at the bottom). This seems indirectly related to bug 20964. Mark's proposed fix to stop building abi-check at bootstrap time means the IA-64 bootstrap should now succeed. This testcase will still be broken, but now it will only be a make check failure instead of a make bootstrap failure. Typo, you meant PR 20694. FYI, Janis and I have been trading emails about this problem, and I've sent her another proposed patch. (The first one fixed "make install", but made "make check" worse.) So, I think this will get sorted shortly. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Use Bohem's GC for compiler proper in 4.1?
Andrew Haley schrieb: Sam Lauber writes: > I know that Bohem's GC is used in the Java runtime for GCC. > However, the compiler proper itself can _really_ cramp people's > avalible RAM (for those who don't belive me and have Windows w/ > DJGPP, change all the memory controls from `auto' to the highest > value and just try to compile libiberty/regex.c), so my suggestion > is usage of Bohem's GC in the compiler proper itself. Do you have any reason to believe that such a change would reduce memory consumption? I have reason to believe that it would increase performance on low memory systems/large translation units: it seems that current gcc gc performs a full memory scan on each collection, right? at least if gcc uses more memory than physically available it spends a _very_ long time swapping during collections. boehm gc could help here since it is a generational collector. -- Stefan Strasser
Re: gcc and vfp instructions
hi
i have downloaded the gcc4.0 from the gcc web site
and i compiled the above program by the following option
main()
{
float a=88.88,b=99.99,c=0;
c=a*b;
printf("%f",c);
}
arm-elf-gcc -mfpu=vfp -S new.c
but it produces the new.s file without any special kind of (vfp
instructions) instructions.
for example for multiplying a and b they havent used fmuls..
is there any special command line option should b given to produce new.s with
fmuls
thanks
- Original Message -
From: "Richard Earnshaw" <[EMAIL PROTECTED]>
To: "aram bharathi" <[EMAIL PROTECTED]>
Subject: Re: gcc and vfp instructions
Date: Tue, 22 Mar 2005 09:52:20 +
>
> On Tue, 2005-03-22 at 08:51, aram bharathi wrote:
> > hi,
> >i like to know whether gcc can generate vfp instructions..
> >
> > main()
> > {
> > float a=88.88,b=99.99,c=0;
> > c=a+b;
> > printf("%f",c);
> > }
> >
> > i used the following option to compile the above program
> >
> > arm-elf-gcc -mfp=2 -S new.c
> >
> > but it produces the new.s file without any special kind of (vfp
> > instructions) instructions
> > how to generate them using gcc
> >
> > or i have to use inline assembly for this operation for this
> >
> > if then, whether it will be supported on binutils and the gdb simulator
> >
> > thanks
>
> gcc-4.0 will be the first FSF release to have VFP support. CodeSourcery
> have a build of gcc-3.4 on their web site which has VFP support
> included. The options needed to generate the VFP code are described in
> the manual.
>
> R.
--
__
Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.
Powered by Outblaze
Re: Use Bohem's GC for compiler proper in 4.1?
On Fri, Apr 01, 2005 at 06:48:56PM +0200, Stefan Strasser wrote: > Andrew Haley schrieb: > >Sam Lauber writes: > > > I know that Bohem's GC is used in the Java runtime for GCC. > > > However, the compiler proper itself can _really_ cramp people's > > > avalible RAM (for those who don't belive me and have Windows w/ > > > DJGPP, change all the memory controls from `auto' to the highest > > > value and just try to compile libiberty/regex.c), so my suggestion > > > is usage of Bohem's GC in the compiler proper itself. > > > >Do you have any reason to believe that such a change would reduce > >memory consumption? > > > > I have reason to believe that it would increase performance on low > memory systems/large translation units: it seems that current gcc gc > performs a full memory scan on each collection, right? at least if gcc > uses more memory than physically available it spends a _very_ long time > swapping during collections. > boehm gc could help here since it is a generational collector. There are other ways to solve this problem, including creating a generational collector using our existing accurate GC. I've been working on this on-and-off (mostly off at the moment, though). -- Daniel Jacobowitz CodeSourcery, LLC
Re: gcc and vfp instructions
On Fri, 2005-04-01 at 18:09, aram bharathi wrote:
> hi
>
> i have downloaded the gcc4.0 from the gcc web site
> and i compiled the above program by the following option
>
> main()
> {
> float a=88.88,b=99.99,c=0;
> c=a*b;
> printf("%f",c);
> }
>
> arm-elf-gcc -mfpu=vfp -S new.c
>
> but it produces the new.s file without any special kind of (vfp
> instructions) instructions.
>
> for example for multiplying a and b they havent used fmuls..
>
> is there any special command line option should b given to produce new.s with
> fmuls
Yes. You need -mfloat-abi=softfp as well.
R.
Re: RFC: #pragma optimization_level
I know we'd find something like that really handy for some of the
embedded stuff we're doing.
There's the case where we'd like to have the files of a subsystem to
be optimized but we want a handful of functions that directly access
hardware be unoptimized. (We found that the optimization did some
write reordering that the hardware didn't like. ;) )
-Kelly Murphy
On Apr 1, 2005 8:05 AM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> Dale Johannesen <[EMAIL PROTECTED]> writes:
>
> > I've currently got the job of implementing pragma(s) to change
> > optimization level in the middle of a file. This has come up a few
> > times before,
>
> Would it be possible to make it a function attribute? I would
> really like to have
>
> void __attribute__((optimization("Os"))) slow_init_function(void)
> {
> }
>
> to let slow_init_function be compiled as space efficient as possible.
>
> I think that would be very useful for the Linux kernel at least.
> There is already a __init modifier for functions that ought to be
> freed after initialization and it would be nice to just add a one
> liner to make them smaller too.
>
> In addition letting the compiler do that automatically based
> on profile feedback for "cold" functions would be very cool.
>
> -Andi
>
Re: RFC: #pragma optimization_level
On Fri, Apr 01, 2005 at 10:16:44AM -0800, Kelly Murphy wrote: > I know we'd find something like that really handy for some of the > embedded stuff we're doing. > > There's the case where we'd like to have the files of a subsystem to > be optimized but we want a handful of functions that directly access > hardware be unoptimized. (We found that the optimization did some > write reordering that the hardware didn't like. ;) ) Are you using "volatile" correctly? There are situations where "volatile" alone does not suffice and you need more locking, but the Linux and BSD kernel folks manage to optimize their device driver code.
Re: i want to connect gcc's front-end to my'back-end
a) what makes your backend different from gcc's backend so it is worth porting it? 하태준 schrieb: > sorry, my english is not good, > > Umm... > > my project is that Connect to Gcc's front-end and My back-end > > first gcc parse sorce code there is an IR created while parsing which is simply called "Trees" and is documented here: http://gcc.gnu.org/onlinedocs/gccint/Trees.html#Trees this is probably what you want. start gdb debugger, break at function cp_finish_file and write "display debug_tree(global_namespace)". you should see a dump of the global namespace. > my back-end has own IR that's based on C++. > > and, my back-end has connect EDG's Front-end > > EDG's Front-end parse sorce program and make EDG's IR > > and EDG's IR translate our IR and our IR make a assemble code > > my project is change EDG's front-end to GCC's front-end because GPL expect some work to do. gcc does some transformations while parsing already, e.g. when calling virtual functions -- Stefan Strasser
Re: RFC: #pragma optimization_level
Dale Johannesen wrote: So I guess question 1 is, Mark, do you feel negatively enough about this feature to block its acceptance in mainline? I'm not sure that I *could* block it, but, no, I don't feel that negatively. I think that a #pragma (or attribute) that affects only optimization options is less problematic than generic option processing (.e.g, flag_writable_strings, as in the email you reference). I do think that you need to clearly document how inlining plays with this. In particular, if you inline a -O2 function into a -O0 function, what happens? (My suggestion would be that the caller's optimization pragmas win.) Also, you should document what set of optimization options can be specified. I think it should only be ones that do not change the ABI; things like -O2, or turning off particular passes are OK, while options that change calling conventions, etc., should be disallowed. Also, you need to say what happens in the situation where the user has done "-O2 -fno-gcse" and the #pragma now says "-O2". Does that reenable GCSE? (I think it should.) -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: RFC: #pragma optimization_level
On Fri, Apr 01, 2005 at 11:24:06AM -0800, Mark Mitchell wrote: > Dale Johannesen wrote: > > >So I guess question 1 is, Mark, do you feel negatively enough about this > >feature to block its acceptance in mainline? > > I'm not sure that I *could* block it, but, no, I don't feel that negatively. > I don't mind either way. But I do have a question, what's the granularity of this #pragma? Function-level, I hope? Diego.
Re: RFC: #pragma optimization_level
Diego Novillo wrote: On Fri, Apr 01, 2005 at 11:24:06AM -0800, Mark Mitchell wrote: Dale Johannesen wrote: So I guess question 1 is, Mark, do you feel negatively enough about this feature to block its acceptance in mainline? I'm not sure that I *could* block it, but, no, I don't feel that negatively. I don't mind either way. But I do have a question, what's the granularity of this #pragma? Function-level, I hope? That's what I assumed. Anything finer than that is insane. :-) -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: i want to connect gcc's front-end to my'back-end
On Thursday, March 31, 2005, at 10:38 PM, GOEBAX wrote: my project is that Connect to Gcc's front-end and My back-end We generally don't support this concept. We'd rather you enhance and extend gcc's back end. Because of this, this is beyond the scope of this list. On topic for this list, would be a discussion of the short comings of the current back end, and ideas for improvements.
Re: Use Bohem's GC for compiler proper in 4.1?
On Friday, April 1, 2005, at 08:48 AM, Stefan Strasser wrote: if gcc uses more memory than physically available it spends a _very_ long time swapping Swapping, what's that? Here's $20, go buy a gigabyte. Now, having said that, we do believe that it would make for interesting research to try less memory intensive algorithms, or to rearrange code so that the working set is reduced to help boost cache hits. Currently gcc takes a cache miss every 20 instructions, or some ungodly number, and that really saps performance. This is, generally speaking, just lots of hard work. Good luck, let us know how it turns out.
Re: RFC: #pragma optimization_level
On Friday, April 1, 2005, at 10:16 AM, Kelly Murphy wrote: There's the case where we'd like to have the files of a subsystem to be optimized but we want a handful of functions that directly access hardware be unoptimized. (We found that the optimization did some write reordering that the hardware didn't like. ;) ) You will want to either, file bug reports for this, or learn to use volatile or stop type tricks... :-)
Re: PR 20505
On Fri, 2005-04-01 at 00:38, Nathan Sidwell wrote: > Here it is, ok? The patch is OK. The ChangeLog entry should refer to INTEGER_CST instead of INT_CST. You are missing a ChangeLog entry for the testcase. The testcase is not portable, as I pointed out in the PR. Trying this on an x86_64-linux system, I get 27 "excess errors" failures. All of them are error: cast from 'int*' to 'int' loses precision Using long works better than int, but is still not fool proof, as there are targets where longs are smaller than pointers. Maybe we can rely on something like ptrdiff_t? -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: PR 20505
James E Wilson wrote: The testcase is not portable, as I pointed out in the PR. Trying this on an x86_64-linux system, I get 27 "excess errors" failures. All of them are error: cast from 'int*' to 'int' loses precision Using long works better than int, but is still not fool proof, as there are targets where longs are smaller than pointers. Maybe we can rely on something like ptrdiff_t? IIRC there's an available cpp #define. I will find it an amend as appropriate. thanks for the review. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: RFC: #pragma optimization_level
On Apr 1, 2005 9:36 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Diego Novillo wrote: > > On Fri, Apr 01, 2005 at 11:24:06AM -0800, Mark Mitchell wrote: > > > >>Dale Johannesen wrote: > >> > >> > >>>So I guess question 1 is, Mark, do you feel negatively enough about this > >>>feature to block its acceptance in mainline? > >> > >>I'm not sure that I *could* block it, but, no, I don't feel that negatively. > >> > > > > I don't mind either way. But I do have a question, what's the > > granularity of this #pragma? Function-level, I hope? > > That's what I assumed. Anything finer than that is insane. :-) Well, if we're inventing something that can annotate functions we may as well invent it in a way that it can be extended to handle statement annotations. Just like for for (;;) #pragma inline foo(); I guess all this (annotating) would fit nicely with the gOMP project, so maybe coordinating the #pragma parsing and storing of the annotation with them would be a good idea. Richard.
Re: RFC: #pragma optimization_level
Richard Guenther wrote: On Apr 1, 2005 9:36 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote: Diego Novillo wrote: On Fri, Apr 01, 2005 at 11:24:06AM -0800, Mark Mitchell wrote: Dale Johannesen wrote: So I guess question 1 is, Mark, do you feel negatively enough about this feature to block its acceptance in mainline? I'm not sure that I *could* block it, but, no, I don't feel that negatively. I don't mind either way. But I do have a question, what's the granularity of this #pragma? Function-level, I hope? That's what I assumed. Anything finer than that is insane. :-) Well, if we're inventing something that can annotate functions we may as well invent it in a way that it can be extended to handle statement annotations. Just like for for (;;) #pragma inline foo(); The concept I was calling insane was trying to optimize the first half of a function with -O2 and the second half with -O0. Your example is different; you're talking about how to treat the call to "foo", not how to optimize the entire function (including the "for"). Something like what you're suggesting doesn't seem entirely unreasonable to me. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: RFC: #pragma optimization_level
Diego Novillo <[EMAIL PROTECTED]> writes:
| On Fri, Apr 01, 2005 at 11:24:06AM -0800, Mark Mitchell wrote:
| > Dale Johannesen wrote:
| >
| > >So I guess question 1 is, Mark, do you feel negatively enough about this
| > >feature to block its acceptance in mainline?
| >
| > I'm not sure that I *could* block it, but, no, I don't feel that negatively.
| >
| I don't mind either way. But I do have a question, what's the
| granularity of this #pragma? Function-level, I hope?
o, what happens, if I have tings like this
#pragma optimization_level whatever
struct A {
void f();
void g();
};
Do A::f() and A::g() get affected?
-- Gaby
Re: RFC: #pragma optimization_level
On Apr 1, 2005, at 11:24 AM, Mark Mitchell wrote: Dale Johannesen wrote: So I guess question 1 is, Mark, do you feel negatively enough about this feature to block its acceptance in mainline? I'm not sure that I *could* block it, but, no, I don't feel that negatively. Well, in theory nobody can block anything (although some people's posts suggest they don't understand this). In practice if you or another GWM objects to something, nobody else is going to override you and approve it. I tried to address your other questions in my previous message, but: I think that a #pragma (or attribute) that affects only optimization options is less problematic than generic option processing (.e.g, flag_writable_strings, as in the email you reference). I do think that you need to clearly document how inlining plays with this. In particular, if you inline a -O2 function into a -O0 function, what happens? (My suggestion would be that the caller's optimization pragmas win.) Agree. (And documentation will be written.) Also, you should document what set of optimization options can be specified. I think it should only be ones that do not change the ABI; things like -O2, or turning off particular passes are OK, while options that change calling conventions, etc., should be disallowed. Agree. Also, you need to say what happens in the situation where the user has done "-O2 -fno-gcse" and the #pragma now says "-O2". Does that reenable GCSE? (I think it should.) Yes. what's the granularity of this #pragma? Function-level, I hope? That's what I assumed. Anything finer than that is insane. :-) Actually there are cases where it makes sense: you could ask that a particular call be inlined, or a particular loop be unrolled N times. However, I'm not planning to do anything finer-grained than a function at the moment. Certainly for optimizations that treat a whole function at once, which is most of them, it doesn't make sense.
Re: RFC: #pragma optimization_level
Dale Johannesen wrote: Agree. (And documentation will be written.) Yay. It sounds like we're definitely on the same page. I think that as long as we keep the semantics clear, this will be useful functionality. That's what I assumed. Anything finer than that is insane. :-) Actually there are cases where it makes sense: you could ask that a particular call be inlined, or a particular loop be unrolled N times. True. Consider my remark regarding insanity qualified to whole-function optimizations. :-) Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: RFC: #pragma optimization_level
On Apr 1, 2005 11:07 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Dale Johannesen wrote: > > Agree. (And documentation will be written.) > > Yay. It sounds like we're definitely on the same page. I think that as > long as we keep the semantics clear, this will be useful functionality. > > >> That's what I assumed. Anything finer than that is insane. :-) > > > > > > Actually there are cases where it makes sense: you could ask that a > > particular call be > > inlined, or a particular loop be unrolled N times. > > True. Consider my remark regarding insanity qualified to whole-function > optimizations. :-) But the question is, do we want all this sort of #pragmas? It would surely better to improve the compilers decisions on applying certain optimizations. As usual, in most of the cases the compiler will be smarter than the user trying to override it (and hereby maybe only working around bugs in a particular compiler release). All opposition that applied to stuff like attribute((leafify)) (hi Gaby!) applies here, too. So what is your opinion to all this babysitting-the-compiler? Just wondering, Richard.
Re: RFC: #pragma optimization_level
Richard Guenther wrote: But the question is, do we want all this sort of #pragmas? It would surely better to improve the compilers decisions on applying certain optimizations. As usual, in most of the cases the compiler will be smarter than the user trying to override it (and hereby maybe only working around bugs in a particular compiler release). All opposition that applied to stuff like attribute((leafify)) (hi Gaby!) applies here, too. So what is your opinion to all this babysitting-the-compiler? Is your objection to a grain finer than the function level? Or is it to the whole concept of having pragmas change the optimization level per function?
Re: RFC: #pragma optimization_level
On Apr 1, 2005 11:23 PM, E. Weddington <[EMAIL PROTECTED]> wrote: > Richard Guenther wrote: > > >But the question is, do we want all this sort of #pragmas? It would > >surely better to improve the compilers decisions on applying certain > >optimizations. As usual, in most of the cases the compiler will be > >smarter than the user trying to override it (and hereby maybe only > >working around bugs in a particular compiler release). All opposition > >that applied to stuff like attribute((leafify)) (hi Gaby!) applies here, too. > >So what is your opinion to all this babysitting-the-compiler? > > > > Is your objection to a grain finer than the function level? Or is it to > the whole concept of having pragmas change the optimization level per > function? It would be a general objection - I thought we're trying to minimize the knobs the user can turn, both for simplicity and maintainance reasons. And I cannot, offhand, think of an example where improving the compiler could not do better than allowing the user specifying optimization options (or parameters -- anyone for changing --param values per function? This would make attribute((leafify)) unnecessary, as I could bump inlining limits for the to-be-leafified functions). Giving fine-grained control to the user should be done only if it is for correctness, not for him to feel better and maybe make one version of the compiler generate slightly better code for him. Richard.
Re: RFC: #pragma optimization_level
Richard Guenther wrote: But the question is, do we want all this sort of #pragmas? It would surely better to improve the compilers decisions on applying certain optimizations. As usual, in most of the cases the compiler will be smarter than the user trying to override it (and hereby maybe only working around bugs in a particular compiler release). All opposition that applied to stuff like attribute((leafify)) (hi Gaby!) applies here, too. So what is your opinion to all this babysitting-the-compiler? I agree, in general. In fact, I've long said that GCC had too many knobs. (For example, I just had a discussion with a customer where I explained that the various optimization passes, while theoretically orthogonal, are not entirely orthogonal in practice, and that truning on another pass (GCSE, in this caes) avoided other bugs. For that reason, I'm not actually convinced that all the -f options for turning on and off passes are useful for end-users, although they are clearly useful for debugging the compiler itself. I think we might have more satisfied users if we simply had -Os, -O0, ..., -O3. However, many people in the GCC community itself, and in certain other vocal areas of the user base, do not agree.) However, function-level optimization control seems to be something lots of people really want, and other compilers do offer it. I think it can be particularly useful to people who want to work around compiler bugs in a particular routine, without refactoring their code, or losing all optimization for a translation unit. Finer-grained optimization control seems like something that should indeed have to pass a relatively strong utility test. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: memcpy(a,b,CONST) is not inlined by gcc 3.4.1 in Linux kernel
> On Wednesday 30 March 2005 05:27, Gerold Jury wrote:
> >
> > >> On Tue, Mar 29, 2005 at 05:37:06PM +0300, Denis Vlasenko wrote:
> > >> > /*
> > >> > * This looks horribly ugly, but the compiler can optimize it totally,
> > >> > * as the count is constant.
> > >> > */
> > >> > static inline void * __constant_memcpy(void * to, const void * from,
> > >> > size_t n) {
> > >> > if (n <= 128)
> > >> > return __builtin_memcpy(to, from, n);
> > >>
> > >> The problem is that in GCC < 4.0 there is no constant propagation
> > >> pass before expanding builtin functions, so the __builtin_memcpy
> > >> call above sees a variable rather than a constant.
> > >
> > >or change "size_t n" to "const size_t n" will also fix the issue.
> > >As we do some (well very little and with inlining and const values)
> > >const progation before 4.0.0 on the trees before expanding the builtin.
> > >
> > >-- Pinski
> > >-
> > I used the following "const size_t n" change on x86_64
> > and it reduced the memcpy count from 1088 to 609 with my setup and gcc
> > 3.4.3.
> > (kernel 2.6.12-rc1, running now)
>
> What do you mean, 'reduced'?
>
> (/me is checking)
>
> Oh shit... It still emits half of memcpys, to be exact - for
> struct copies:
>
> arch/i386/kernel/process.c:
>
> int copy_thread(int nr, unsigned long clone_flags, unsigned long esp,
> unsigned long unused,
> struct task_struct * p, struct pt_regs * regs)
> {
> struct pt_regs * childregs;
> struct task_struct *tsk;
> int err;
>
> childregs = ((struct pt_regs *) (THREAD_SIZE + (unsigned long)
> p->thread_info)) - 1;
> *childregs = *regs;
> ^^^
> childregs->eax = 0;
> childregs->esp = esp;
>
> # make arch/i386/kernel/process.s
>
> copy_thread:
> pushl %ebp
> movl%esp, %ebp
> pushl %edi
> pushl %esi
> pushl %ebx
> subl$20, %esp
> movl24(%ebp), %eax
> movl4(%eax), %esi
> pushl $60
> leal8132(%esi), %ebx
> pushl 28(%ebp)
> pushl %ebx
> callmemcpy <=
> movl$0, 24(%ebx)
> movl16(%ebp), %eax
> movl%eax, 52(%ebx)
> movl24(%ebp), %edx
> addl$8192, %esi
> movl%ebx, 516(%edx)
> movl%esi, -32(%ebp)
> movl%esi, 504(%edx)
> movl$ret_from_fork, 512(%edx)
>
> Jakub, is there a way to instruct gcc to inine this copy, or better yet,
> to use user-supplied inline version of memcpy?
You can't inline struct copy as it is not function call at first place.
You can experiment with -minline-all-stringops where GCC will use it's
own memcpy implementation for this.
Honza
> --
> vda
Re: RFC: #pragma optimization_level
Richard Guenther wrote: On Apr 1, 2005 11:23 PM, E. Weddington <[EMAIL PROTECTED]> wrote: Is your objection to a grain finer than the function level? Or is it to the whole concept of having pragmas change the optimization level per function? It would be a general objection - I thought we're trying to minimize the knobs the user can turn, both for simplicity and maintainance reasons. And I cannot, offhand, think of an example where improving the compiler could not do better than allowing the user specifying optimization options (or parameters -- anyone for changing --param values per function? This would make attribute((leafify)) unnecessary, as I could bump inlining limits for the to-be-leafified functions). Giving fine-grained control to the user should be done only if it is for correctness, not for him to feel better and maybe make one version of the compiler generate slightly better code for him. That would not be the only reason Mark Mitchell wrote: In fact, I've long said that GCC had too many knobs. (For example, I just had a discussion with a customer where I explained that the various optimization passes, while theoretically orthogonal, are not entirely orthogonal in practice, and that truning on another pass (GCSE, in this caes) avoided other bugs. For that reason, I'm not actually convinced that all the -f options for turning on and off passes are useful for end-users, although they are clearly useful for debugging the compiler itself. I think we might have more satisfied users if we simply had -Os, -O0, ..., -O3. However, many people in the GCC community itself, and in certain other vocal areas of the user base, do not agree.) (As an OT aside: what about increasing the number of optimization levels to handle fine grain control of the -f options for turning on/off passes? Let me know if this has been discussed and rejected previously; a link would be nice.) However, function-level optimization control seems to be something lots of people really want, and other compilers do offer it. I think it can be particularly useful to people who want to work around compiler bugs in a particular routine, without refactoring their code, or losing all optimization for a translation unit. Finer-grained optimization control seems like something that should indeed have to pass a relatively strong utility test. This has been an oft-requested feature in the AVR community (and I would also add for the wider embedded community), not so much to work around compiler issues but to work out space/speed tradeoffs. Many times the embedded user wants practically all of the code to be optimized for space except for the few timing cricital functions that need to be compiled for speed to run as fast as possible. There are cases where it is terribly inconvenient to seperate these functions into seperate files (e.g. access to C static variables). The compiler cannot easily make this design decision. So this feature is very much desired. As to anything more fine-grained than functions (which I agree is insanity), or the whole inlining mess, I'll leave that to experts. Thanks Eric
Re: RFC: #pragma optimization_level
Joe Buck wrote:
Are you using "volatile" correctly? There are situations where "volatile"
alone does not suffice and you need more locking, but the Linux and BSD
kernel folks manage to optimize their device driver code.
We have just been discussing a similar topic in a de.* newsgroup.
A busy-loop function is used to effect a delay, not too precise,
but portably. Like
#define COUNT 1000
void f() {
/*volatile*/ /*register*/ int i;
for (i = 0; i < COUNT; ++i)
;
}
If volatile is used to instruct the compiler to actually produce
a loop even when optimizing, then we get copying from/to the stack,
or memory access (ARM). What the compiler users have expected their
compiler to do is to produce an obvious loop using registers.
This doesn't always happen, and in addition some strange looking
copy-back-and-forth instructions are generated, like
move x, y
move y, x
(ARM, Intel)
The user said that all this was not what he had said (in a loop
like the one above).
Can there be a pragma instructing the compiler to do (ÏÏ)
as I say, in source text?
Re: RFC: #pragma optimization_level
Georg Bauhaus wrote:
We have just been discussing a similar topic in a de.* newsgroup.
A busy-loop function is used to effect a delay, not too precise,
but portably. Like
#define COUNT 1000
void f() {
/*volatile*/ /*register*/ int i;
for (i = 0; i < COUNT; ++i)
;
}
If volatile is used to instruct the compiler to actually produce
a loop even when optimizing, then we get copying from/to the stack,
or memory access (ARM). What the compiler users have expected their
compiler to do is to produce an obvious loop using registers.
What do you get if you use the C99 construct of declaring the variable
in the for statement? Like so:
for(volatile int i = 0; i < COUNT; ++i);
Eric
Re: RFC: #pragma optimization_level
Georg Bauhaus <[EMAIL PROTECTED]> writes:
| Joe Buck wrote:
|
| > Are you using "volatile" correctly? There are situations where "volatile"
| > alone does not suffice and you need more locking, but the Linux and BSD
| > kernel folks manage to optimize their device driver code.
|
| We have just been discussing a similar topic in a de.* newsgroup.
| A busy-loop function is used to effect a delay, not too precise,
| but portably. Like
|
| #define COUNT 1000
|
| void f() {
|/*volatile*/ /*register*/ int i;
|
|for (i = 0; i < COUNT; ++i)
| ;
This must be an FAQ. The above is no way of (no matter how popular
the urban legend makes it) implementing delay. Adding a #pragma just
makes teh situation worse.
-- Gaby
Re: RFC: #pragma optimization_level
Georg Bauhaus <[EMAIL PROTECTED]> writes:
> | A busy-loop function is used to effect a delay, not too precise,
> | but portably. Like
> |
> | #define COUNT 1000
> |
> | void f() {
> |/*volatile*/ /*register*/ int i;
> |
> |for (i = 0; i < COUNT; ++i)
> | ;
On Sat, Apr 02, 2005 at 01:48:56AM +0200, Gabriel Dos Reis wrote:
> This must be an FAQ. The above is no way of (no matter how popular
> the urban legend makes it) implementing delay. Adding a #pragma just
> makes teh situation worse.
Unfortunately, where there is a good argument for not using empty loops
as busy-waits, at one time it was documented GCC behavior that it would
work, so we can't really blame the users for trusting the doc.
That's not to say that it was ever a good idea, because of the lack of
control. If you need a precisely timed busy-wait, an inline assembly
construct is the best bet.
Re: RFC: #pragma optimization_level
> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
Joe> Georg Bauhaus <[EMAIL PROTECTED]> writes:
>> | A busy-loop function is used to effect a delay, not too precise,
>> | but portably. Like
>> |
>> | #define COUNT 1000
>> |
>> | void f() { | /*volatile*/ /*register*/ int i;
>> |
>> | for (i = 0; i < COUNT; ++i)
>> | ;
Joe> On Sat, Apr 02, 2005 at 01:48:56AM +0200, Gabriel Dos Reis
Joe> wrote:
>> This must be an FAQ. The above is no way of (no matter how
>> popular the urban legend makes it) implementing delay. Adding a
>> #pragma just makes teh situation worse.
Joe> Unfortunately, where there is a good argument for not using
Joe> empty loops as busy-waits, at one time it was documented GCC
Joe> behavior that it would work, so we can't really blame the users
Joe> for trusting the doc.
Would this work:
for (i=0; i < foo; i++)
asm volatile ("");
Or perhaps with asm volatile ("":::"memory") instead?
paul
Re: RFC: #pragma optimization_level
Joe Buck wrote:
Georg Bauhaus <[EMAIL PROTECTED]> writes:
| A busy-loop function is used to effect a delay, not too precise,
| but portably. Like
|
| #define COUNT 1000
|
| void f() {
|/*volatile*/ /*register*/ int i;
|
|for (i = 0; i < COUNT; ++i)
| ;
Unfortunately, where there is a good argument for not using empty loops
as busy-waits, at one time it was documented GCC behavior that it would
work, so we can't really blame the users for trusting the doc.
That's not to say that it was ever a good idea, because of the lack of
control. If you need a precisely timed busy-wait, an inline assembly
construct is the best bet.
Yeah, but that just raises the "barrier for entry" for a lot of people
starting out in e.g. embedded programming. It's much easier to throw
together a do-nothing for loop in C then it is to try and wade through
understanding how to do GCC inline assembly. Would it be reasonable to
implement what Georg wants iff volatile and register are used, even if
it has to be restricted to the C99 construct?:
for(register volatile int i = 0; i < COUNT; ++i);
I know it's terribly inaccurate as a delay, and it should be
discouraged, but unfortunately it seems to be a common idiom in embedded
code.
Thanks
Eric
gcc-3.4-20050401 is now available
Snapshot gcc-3.4-20050401 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050401/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 3.4 CVS branch with the following options: -rgcc-ss-3_4-20050401 You'll find: gcc-3.4-20050401.tar.bz2 Complete GCC (includes all of below) gcc-core-3.4-20050401.tar.bz2 C front end and core compiler gcc-ada-3.4-20050401.tar.bz2 Ada front end and runtime gcc-g++-3.4-20050401.tar.bz2 C++ front end and runtime gcc-g77-3.4-20050401.tar.bz2 Fortran 77 front end and runtime gcc-java-3.4-20050401.tar.bz2 Java front end and runtime gcc-objc-3.4-20050401.tar.bz2 Objective-C front end and runtime gcc-testsuite-3.4-20050401.tar.bz2The GCC testsuite Diffs from 3.4-20050325 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-3.4 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: Problems using cfg_layout_finalize()
On Fri, 2005-01-04 at 00:10 -0500, Grzegorz B. Prokopski wrote: > /* Leave the rest as it was. */ > FOR_EACH_BB (bb) > if ((bb->next_bb != EXIT_BLOCK_PTR) && (!bb->rbi->next)) > bb->rbi->next = bb->next_bb; This code worked well in some other place from which I copied it, but unfortunatelly for the kind of reordering I do the above makes some BBs be referenced twice as bb->rbi->next, from two different BBs. I needed to use a more complicated method of setting the order of the "rest" of BBs. Grzegorz B. Prokopski PS: Thanks to the person who offered help off-list.
Re: RFC: #pragma optimization_level
On 2005-04-01, at 23:17, Richard Guenther wrote: On Apr 1, 2005 11:07 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote: Dale Johannesen wrote: Agree. (And documentation will be written.) Yay. It sounds like we're definitely on the same page. I think that as long as we keep the semantics clear, this will be useful functionality. That's what I assumed. Anything finer than that is insane. :-) Actually there are cases where it makes sense: you could ask that a particular call be inlined, or a particular loop be unrolled N times. True. Consider my remark regarding insanity qualified to whole-function optimizations. :-) But the question is, do we want all this sort of #pragmas? It would surely better to improve the compilers decisions on applying certain optimizations. As usual, in most of the cases the compiler will be smarter than the user trying to override it (and hereby maybe only working around bugs in a particular compiler release). Compilers are good. But they still don't think. And they don't have a clue about the input characteristics and thus affected runtime behavior of the code. Sometimes you definitively want to switch the optimizers GOALS at the level of a single file. Or in other words: you want to provide additional information about the runtime of the code to the compiler for better optimization decisions. Like for example optimizing the whole system for size but letting him optimize some well identified hot-spot functions for speed.
Re: RFC: #pragma optimization_level
On 2005-04-01, at 23:36, Mark Mitchell wrote: Richard Guenther wrote: But the question is, do we want all this sort of #pragmas? It would surely better to improve the compilers decisions on applying certain optimizations. As usual, in most of the cases the compiler will be smarter than the user trying to override it (and hereby maybe only working around bugs in a particular compiler release). All opposition that applied to stuff like attribute((leafify)) (hi Gaby!) applies here, too. So what is your opinion to all this babysitting-the-compiler? I agree, in general. In fact, I've long said that GCC had too many knobs. (For example, I just had a discussion with a customer where I explained that the various optimization passes, while theoretically orthogonal, are not entirely orthogonal in practice, and that truning on another pass (GCSE, in this caes) avoided other bugs. For that reason, I'm not actually convinced that all the -f options for turning on and off passes are useful for end-users, although they are clearly useful for debugging the compiler itself. I think we might have more satisfied users if we simply had -Os, -O0, ..., -O3. However, many people in the GCC community itself, and in certain other vocal areas of the user base, do not agree.) I think the point here is not quite the number of options but the character they currently frequently have. Currently you tell the means about what the compiler should do: -fdo-this-and-that-obscure-optimization. I think that most people would prefer to state goals: -ftry-to-achive-small-code-size (like -Os) -fplese-try-to-be-nice-to-foo -fplease-dont-care-about-aliasing. -fgive-me-well-debuggable-code-I-dont-care-now-for-execution-speed -fdo-as-much-as-you-think-is-good-for-execution-speed (Ok that one exists: -O9) Thus the -Ox family is what people like. More of it would be good and the -f family indeed degraded to compiler development help.
Re: Use Bohem's GC for compiler proper in 4.1?
Mike Stump schrieb: On Friday, April 1, 2005, at 08:48 AM, Stefan Strasser wrote: if gcc uses more memory than physically available it spends a _very_ long time swapping Swapping, what's that? Here's $20, go buy a gigabyte. expect memory to become a problem again with the advent of multicore and people wanting to run more than one gcc at a time. I do have swapping on a 1 GB machine with 2 CPUs(-> 2 GCCs) but that wasn't my argument, swapping was just what made me assume that gcc gc does a full memory scan on each collection. non-generational gc also performs bad without swapping on large heaps. but I understand the objection that you want to keep exact GC(although I'm not enough into gc to decide if it's worth it). -- Stefan Strasser
Re: RFC: #pragma optimization_level
Gabriel Dos Reis wrote:
| void f() {
|/*volatile*/ /*register*/ int i;
|
|for (i = 0; i < COUNT; ++i)
| ;
This must be an FAQ. The above is no way of (no matter how popular
the urban legend makes it) implementing delay.
As a normative statement, a busy loop might not be the
way to implement delay. But the guys are working
with essentially a CPU and nothing else to help it.
No timers, no external clock, nothing.
So as a matter of fact, there is no choice but to use
a loop. The question they ask then is, can I instruct
the compiler to turn the above loop into a loop at
object code level, and can I say so in the source text,
visible to following programmer generations?
volatile might be a first step. However, a number
of gcc users will be more happy when they can
instruct the compiler to turn an empty C loop into
an object code loop using a register for counting.
I can't say what the proportion of gcc users is who
want this feature, but it isn't 0.0.
Re: RFC: #pragma optimization level
> Joe Buck wrote:
>>Georg Bauhaus <[EMAIL PROTECTED]> writes:
>> | A busy-loop function is used to effect a delay, not too precise,
>> | but portably. Like
>> |
>> | #define COUNT 1000
>> |
>> | void f() {
>> |/*volatile*/ /*register*/ int i;
>> |
>> |for (i = 0; i < COUNT; ++i)
>> | ;
>
> >On Sat, Apr 02, 2005 at 01:48:56AM +0200, Gabriel Dos Reis wrote:
>> This must be an FAQ. The above is no way of (no matter how popular
>> the urban legend makes it) implementing delay. Adding a #pragma just
>> makes teh situation worse.
>
> Unfortunately, where there is a good argument for not using empty loops
> as busy-waits, at one time it was documented GCC behavior that it would
> work, so we can't really blame the users for trusting the doc.
>
> That's not to say that it was ever a good idea, because of the lack of
> control. If you need a precisely timed busy-wait, an inline assembly
> construct is the best bet.
Fully agree, a C based delay loop which easily has a 2x margin of error
is basically useless (even if the clock frequency were precisely known).
Re: Use Bohem's GC for compiler proper in 4.1?
Stefan Strasser wrote: Mike Stump schrieb: On Friday, April 1, 2005, at 08:48 AM, Stefan Strasser wrote: if gcc uses more memory than physically available it spends a _very_ long time swapping Swapping, what's that? Here's $20, go buy a gigabyte. expect memory to become a problem again with the advent of multicore and people wanting to run more than one gcc at a time. I do have swapping on a 1 GB machine with 2 CPUs(-> 2 GCCs) Memory bloat is a problem for embedded systems. Attitudes about just "buy another gigabyte" is why i use C for everything for speed, portability, compactness, and conciseness of design. but that wasn't my argument, swapping was just what made me assume that gcc gc does a full memory scan on each collection. non-generational gc also performs bad without swapping on large heaps. but I understand the objection that you want to keep exact GC(although I'm not enough into gc to decide if it's worth it).
Re: Use Bohem's GC for compiler proper in 4.1?
> I do have swapping on a 1 GB machine with 2 CPUs(-> 2 GCCs) If you can demonstrate that say GCC-4.0 uses much more memory than 3.4 or 3.3 to compile some code, then file a PR with preprocessed source and someone will eventually look at it. Don't compare current GCC to 3.2 since the collection heuristics were changed from hardcoded to dynamic as of 3.3 and so comparing newer gcc to 3.2 or previous isn't apples-to-apples. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: GNU toolchain for blackfin processor
Vinayak Ghate wrote: Do we have GNU toolchain for blackfin processor?? Can anybody help me out in this regard?? I was mistaken. The Blackfin port has already been submitted, but not yet added to our source code repository. There is a chance that it may end up in the upcoming release, gcc-4.0. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: GCC 4.1 bootstrap failed at ia64-*-linux
Zagorodnev, Grigory wrote: How it is possible that recent cgraph changes affect ia64 compiler behavior? I see reclaimed callgraph differs on ia64 but not on ia32; therefore ia32/x86_64 compiler remains stable. This is presumably the same problem that is now PR 20717. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: RFC: #pragma optimization_level
E. Weddington wrote: What do you get if you use the C99 construct of declaring the variable in the for statement? Like so: for(volatile int i = 0; i < COUNT; ++i); I get the same code afaics. In fact, I haven't been able to produce an empty loop that isn't translated into an actual loop, volatile or not. So maybe someone raised false alarm, and I'm guilty of reporting it. volatile adds instructions for copying registers to somewhere else and back, but even without volatile the loop is made for -O[0123]. Excerpt for x86, similarly for PPC: (0x3b9ac9ff == 10) 20:8b 45 fc mov0xfffc(%ebp),%eax 23:40 inc%eax 24:89 45 fc mov%eax,0xfffc(%ebp) 27:8b 45 fc mov0xfffc(%ebp),%eax 2a:3d ff c9 9a 3b cmp$0x3b9ac9ff,%eax 2f:7e efjle20 versus 8:40 inc%eax 9:3d 00 ca 9a 3b cmp$0x3b9aca00,%eax e:75 f8jne8 Another issue illustrating how this was discussed in de.* was along the lines of strlen(x) == strlen(x) being optimized away. So it is useless in an attempt to make the computer work unless one (a) insists on using strlen and (b) instructs the compiler not to optimize the comparison away e.g. using a #pragma ...
Re: Use Bohem's GC for compiler proper in 4.1?
On Apr 1, 2005, at 10:11 PM, Russell Shaw wrote: Stefan Strasser wrote: Mike Stump schrieb: On Friday, April 1, 2005, at 08:48 AM, Stefan Strasser wrote: if gcc uses more memory than physically available it spends a _very_ long time swapping Swapping, what's that? Here's $20, go buy a gigabyte. expect memory to become a problem again with the advent of multicore and people wanting to run more than one gcc at a time. I do have swapping on a 1 GB machine with 2 CPUs(-> 2 GCCs) Memory bloat is a problem for embedded systems. Attitudes about just "buy another gigabyte" is why i use C for everything for speed, portability, compactness, and conciseness of design. But you are not compiling on the embedded machine :). That is the point of Mike Stump, nothing else. -- Pinski
Re: Use Bohem's GC for compiler proper in 4.1?
On Sat, Apr 02, 2005 at 01:10:42AM -0500, Andrew Pinski wrote: > >Memory bloat is a problem for embedded systems. Attitudes about just > >"buy > >another gigabyte" is why i use C for everything for speed, portability, > >compactness, and conciseness of design. > > But you are not compiling on the embedded machine :). > > That is the point of Mike Stump, nothing else. We should still care about memory consumption, because older machines sometimes have limited expandability (there are laptops added today that cannot take more than 512Mb, and that's a current machine). Folks in third-world countries with cast-off machines should be able to use GCC.
