RFC: Plan for cleaning up the "Addressing Modes" macros

The target macros described in the "Addressing Modes" section of the internals manual are rather badly in need of cleaning up. I see three primary reasons why this is so: 1) These are the macros subject to REG_OK_STRICT. For those of you who have managed so far to avoid finding out about thi

Re: GCC 4.1 Projects

On Feb 27, 2005, at 3:59 PM, Daniel Berlin wrote: In stark contrast, i believe it is a very good idea for us to be "over organized" about this. As for judging importance, the release manager has always judged what is important for a given release, based on general goals. I agree. IMO taking one mo

Re: GCC 4.1 Projects

> s/could/absolutely will/. It's a remarkably strong incentive not to > submit project proposals for 4.2. Sadly, that's true, if people want to game the system. Whether or not people do it, the *incentive* still exists and I worry a bit about creating an incentive to "game the syst

Re: Inlining and estimate_num_insns

Steven Bosscher <[EMAIL PROTECTED]> writes: [...] | I can only wonder why we are having this discussion just after GCC 4.0 | was branched, while it was obvious already two years ago that inlining | heuristics were going to be a difficult item with tree-ssa. my recollection and own feeling is tha

Re: Inlining and estimate_num_insns

"Giovanni Bajo" <[EMAIL PROTECTED]> writes: [...] | > The kinds of programs | > written by these two communities are drastically different, even | > though, obviously, there is overlap between the two, mixed programs, | > etc. But, programmers in one camp tend to think that their style is | > "v

Re: GCC 4.1 Projects

Zdenek Dvorak wrote: I think it's a little early to start the post-mortem. Perhaps in Stage 3, we could have a better discussion about how well this worked out. Or, perhaps it will become obvious before then, one way or the other. agreed. Anyway, thank you for all the work you spend on trying

Re: GCC 4.1 Projects

Daniel Jacobowitz wrote: The Stage 1 schedule looks full to me, and I'd like to see those patches go in soon so that we can start shaking out the inevitable problems. I'm much less worried about the long-term impact of Nathanael's patch; if it breaks something, it will get fixed, and then that w

Re: Inlining and estimate_num_insns

Giovanni Bajo wrote: Mark Mitchell <[EMAIL PROTECTED]> wrote: 1. The C++ community has split into two sub-communities. One is very heavily focused on template metaprogramming. The other is doing more "traditional" object-oriented programming. I would postulate that most of the times the former

Re: Inlining and estimate_num_insns

On Monday 28 February 2005 01:46, Giovanni Bajo wrote: > Richard showed already how his patches help on some of the benchamarks you > suggested. They also fix a regression since 3.4 was so much better in this > regard. And it may introduce new ones. > Of course, compilation time goes up somehow b

Re: Implicit altivec vs. linux kernel build

On Sun, 2005-02-27 at 19:32 -0500, David Edelsohn wrote: > > Benjamin Herrenschmidt writes: > > Ben> The only problem I see is that the day we have a CPU, let's call it > Ben> POWER8 for the sake of this demonstration, that has altivec and is > Ben> different enough to justify a specific "opti

Re: GCC 4.1 Projects

On Sun, Feb 27, 2005 at 03:56:26PM -0800, Mark Mitchell wrote: > Daniel Jacobowitz wrote: > >On Sun, Feb 27, 2005 at 02:57:05PM -0800, Mark Mitchell wrote: > > >Nathanael said it did not interfere with any of the other _projects_, > >not that it would be disjoint from all Stage 1 _patches_. > > F

Re: Inlining and estimate_num_insns

On Feb 27, 2005, at 7:46 PM, Giovanni Bajo wrote: Richard showed already how his patches help on some of the benchamarks you suggested. They also fix a regression since 3.4 was so much better in this regard. Of course, compilation time goes up somehow because we are doing more work now, but the

Re: Inlining and estimate_num_insns

Mark Mitchell <[EMAIL PROTECTED]> wrote: > 1. The C++ community has split into two sub-communities. One is very > heavily focused on template metaprogramming. The other is doing more > "traditional" object-oriented programming. I would postulate that most of the times the former group are those

Re: Inlining and estimate_num_insns

Steven Bosscher <[EMAIL PROTECTED]> wrote: >> In the end we surely want to watch CiSBE and SPEC testers. > > Maybe so, but your timings already show this is pretty unacceptable. I strongly object this. Benchmarks show that we are doing *much* worse at inlining in 4.0, and we are seeing bad regre

Re: Implicit altivec vs. linux kernel build

> Benjamin Herrenschmidt writes: Ben> The only problem I see is that the day we have a CPU, let's call it Ben> POWER8 for the sake of this demonstration, that has altivec and is Ben> different enough to justify a specific "optimize" option, we'll have to Ben> use -mcpu=POWER8 -mno-altivec for

Re: GCC 4.1 Projects

Hello, > >at the beginning of the stage 1, there always is lot of major changes > >queued up. It never lead to unmanageable amount of "breakage and > >disruption". > > Other people have a different perception than you do. > > >As for constructive suggestions -- why not just forget on whole plan

Re: GCC 4.1 Projects

at the beginning of the stage 1, there always is lot of major changes queued up. It never lead to unmanageable amount of "breakage and disruption". Other people have a different perception than you do. As for constructive suggestions -- why not just forget on whole plan and let the things work out

Re: Implicit altivec vs. linux kernel build

On Sun, 2005-02-27 at 18:56 -0500, David Edelsohn wrote: > > Benjamin Herrenschmidt writes: > > Ben> Ok. What I need is -mcpu=power4 -maltivec > > Sorry, no. -maltivec means generate Altivec code, not just enable > Altivec instructions and registers. The above option is not different

Re: GCC 4.1 Projects

Hello, > (This time around, the there seemed to be consensus that all proposals > be made public upon submission. Since that seems to be the consensus, > I'll implement that in the next release cycle.) yes, this would definitely make sense. Zdenek

Re: GCC 4.1 Projects

Hello, > > Zdenek Dvorak writes: > > Zdenek> I must admit I have very bad feeling about the whole "4.1 Projects" > Zdenek> stuff. IMHO this over-organizes things. If people in general > disagree > Zdenek> with the Nathan's changes, or if there are any reasons to think that > Zdenek> they a

Re: Implicit altivec vs. linux kernel build

On Feb 27, 2005, at 6:56 PM, David Edelsohn wrote: Benjamin Herrenschmidt writes: Ben> Ok. What I need is -mcpu=power4 -maltivec Sorry, no. -maltivec means generate Altivec code, not just enable Altivec instructions and registers. The above option is not different than -mcpu=970. There i

Re: GCC 4.1 Projects

On Mon, 2005-02-28 at 00:38 +0100, Zdenek Dvorak wrote: > Hello, > > > >Although you have listed it as "stage 2", I wish to commit the finished > > >portion as soon as possible during stage 1. I have maintainership > > >authority > > >to do so. This will not interfere in any way with *any* of t

Re: GCC 4.1 Projects

Zdenek Dvorak wrote: Hello, But I don't think having just a single person decide which patches may go in and which must wait, or even just judging their importance, is a good idea. People weren't happy with the ad-hoc nature of the process before, and I got a lot of mail about the mainline being

Re: GCC 4.1 Projects

Daniel Jacobowitz wrote: On Sun, Feb 27, 2005 at 02:57:05PM -0800, Mark Mitchell wrote: Nathanael said it did not interfere with any of the other _projects_, not that it would be disjoint from all Stage 1 _patches_. Fair point. I would certainly prefer that you hold off until Stage 2, as indicated

Re: Implicit altivec vs. linux kernel build

> Benjamin Herrenschmidt writes: Ben> Ok. What I need is -mcpu=power4 -maltivec Sorry, no. -maltivec means generate Altivec code, not just enable Altivec instructions and registers. The above option is not different than -mcpu=970. There is no DWIM option. David

Re: GCC 4.1 Projects

> Zdenek Dvorak writes: Zdenek> I must admit I have very bad feeling about the whole "4.1 Projects" Zdenek> stuff. IMHO this over-organizes things. If people in general disagree Zdenek> with the Nathan's changes, or if there are any reasons to think that Zdenek> they are not tested enough or

Re: Implicit altivec vs. linux kernel build

On Sun, 2005-02-27 at 18:40 -0500, Andrew Pinski wrote: > On Feb 27, 2005, at 6:35 PM, David Edelsohn wrote: > > > As Andrew Pinski mentioned, you also can use -mcpu=970 > > -mno-altivec. That should allow the assembler to accept Altivec > > instructions, but GCC will not know about any Altiv

building Microchip's pic30 dsPIC version of binutils and GCC

Microchip distribute a modified GCC which targets their dsPIC series of microcontrollers. It took me a while to figure out how to build it properly on GNU/Linux, so I'm documenting the patches required for posterity. These patches apply against Microchip's version 1.30, available from

Re: Implicit altivec vs. linux kernel build

On Mon, Feb 28, 2005 at 10:00:42AM +1100, Benjamin Herrenschmidt wrote: > Oh, and there are gcc version that will refuse -mcpu=power4 -maltivec so > I can't even use -mcpu=power4 for the whole kernel and -maltivec just > for the file containing the raid6 code I guess what you mean here it that the

Re: Implicit altivec vs. linux kernel build

On Feb 27, 2005, at 6:35 PM, David Edelsohn wrote: As Andrew Pinski mentioned, you also can use -mcpu=970 -mno-altivec. That should allow the assembler to accept Altivec instructions, but GCC will not know about any Altivec registers for inlined assembly parameters. As I and Ben found out

Re: GCC 4.1 Projects

Hello, > >Although you have listed it as "stage 2", I wish to commit the finished > >portion as soon as possible during stage 1. I have maintainership > >authority > >to do so. This will not interfere in any way with *any* of the projects > >approved for stage 1, since it is in a disjoint secti

Re: Implicit altivec vs. linux kernel build

> Oh, and there are gcc version that will refuse -mcpu=power4 -maltivec so > I can't even use -mcpu=power4 for the whole kernel and -maltivec just > for the file containing the raid6 code. As Andrew Pinski mentioned, you also can use -mcpu=970 -mno-altivec. That should allow the assembler

Re: Inlining and estimate_num_insns

Re: Inlining and estimate_num_insns

On 2005-02-27, at 23:39, Andrew Pinski wrote: On Feb 27, 2005, at 5:30 PM, Steven Bosscher wrote: Interesting. You of course know Gaby is always claiming the exact opposite: That the compiler must *honor* the inline keyword (explicit or "implicit", ie. inline in class definitions), that inline is

Re: Inlining and estimate_num_insns

On 2005-02-27, at 23:28, Richard Guenther wrote: People already know to use __attribute__((always_inline)) (ugh!), When they discover after countelss ours of debugging dessions during kernel coding that the compiler suddenly and unpredicably doesn't honor what they told him explicitely to do thus

Re: GCC 4.1 Projects

On Feb 27, 2005, at 6:17 PM, Daniel Jacobowitz wrote: I think that you need to be a little more specific when asking a maintainer to hold off on committing a patch that he has authority to commit, desire to commit, and has been maintaining separately - out of deference to the 4.0 schedule - for man

Re: GCC 4.1 Projects

On Sun, Feb 27, 2005 at 02:57:05PM -0800, Mark Mitchell wrote: > Nathanael Nerode wrote: > >The libada-gnattools-branch suffers severely from having to be maintained > >in parallel with mainline (since it's a rearrangment of existing code). > >Another two months of waiting will necessitate many hou

A question about DOM

Hi, Consider the following code from tree-ssa-dom.c:tree_ssa_dominator_optimize. /* Thread jumps, creating duplicate blocks as needed. */ cfg_altered = thread_through_all_blocks (); /* Removal of statements may make some EH edges dead. Purge such edges from the CFG a

Re: Inlining and estimate_num_insns

Andrew Pinski <[EMAIL PROTECTED]> writes: | On Feb 27, 2005, at 5:30 PM, Steven Bosscher wrote: | > Interesting. You of course know Gaby is always claiming the exact | > opposite: That the compiler must *honor* the inline keyword (explicit | > or "implicit", ie. inline in class definitions), that

Re: Implicit altivec vs. linux kernel build

> Yes, but as I wrote, that prevents building the RAID6 code which > contains some selected altivec bits and cause gas to not get passed the > proper option so we can have instructions like "dssall" in the low level > assembly files. > > The later can probably be worked around by adding the prope

Re: Inlining and estimate_num_insns

Richard Guenther <[EMAIL PROTECTED]> writes: [...] | > Of course, if we can make the compiler automatically do the right thing, | > that's great. What I'm proposing is a method that would be possibly | > acceptable for 4.0 that would give people an easy to understand way of | > getting the compi

Re: Inlining and estimate_num_insns

Andrew Pinski wrote: On Feb 27, 2005, at 5:30 PM, Steven Bosscher wrote: Interesting. You of course know Gaby is always claiming the exact opposite: That the compiler must *honor* the inline keyword (explicit or "implicit", ie. inline in class definitions), that inline is not a hint but an order t

Re: Implicit altivec vs. linux kernel build

On Sun, 2005-02-27 at 17:53 -0500, David Edelsohn wrote: > > Benjamin Herrenschmidt writes: > > Ben> There seem to be a problem with gcc 4.0 and implicit generation of > Ben> altivec instructions when -mcpu=970. > > Ben> The problem is that the kernel cannot afford to use altivec instructions

Re: GCC 4.1 Projects

Nathanael Nerode wrote: The libada-gnattools-branch suffers severely from having to be maintained in parallel with mainline (since it's a rearrangment of existing code). Another two months of waiting will necessitate many hours of totally unneccessary work on my part. The same is true for everyone

Re: Implicit altivec vs. linux kernel build

> Benjamin Herrenschmidt writes: Ben> There seem to be a problem with gcc 4.0 and implicit generation of Ben> altivec instructions when -mcpu=970. Ben> The problem is that the kernel cannot afford to use altivec instructions Ben> (nor FPU) except in controlled environment. Specifically, thing

Re: Inlining and estimate_num_insns

Mark Mitchell <[EMAIL PROTECTED]> writes: | A few top-level comments on this thread: | | 1. The C++ community has split into two sub-communities. One is very | heavily focused on template metaprogramming. The other is doing more | "traditional" object-oriented programming. The kinds of program

Re: Implicit altivec vs. linux kernel build

On Sun, 2005-02-27 at 17:47 -0500, Andrew Pinski wrote: > s the proper way or set of options for me to: > > > > 1) optionally have POWER4 optimisations (that must be independant on > > the rest below) > > 2) be able to use altivec instructions in assembly > > 3) be able to use altivec in a few s

Re: Implicit altivec vs. linux kernel build

On Feb 27, 2005, at 5:43 PM, Benjamin Herrenschmidt wrote: Hi ! There seem to be a problem with gcc 4.0 and implicit generation of altivec instructions when -mcpu=970. The problem is that the kernel cannot afford to use altivec instructions (nor FPU) except in controlled environment. Specifically,

Re: GCC 4.1 Projects

Nathan Sidwell wrote: Mark Mitchell wrote: Nathan Sidwell wrote: You've not included the completion of gcc_assertification, did you miss that email, or did you not think it necessary to add it as a specific project, or ... ? The former; I thought we'd corresponded about that previously? It seeme

Implicit altivec vs. linux kernel build

Hi ! There seem to be a problem with gcc 4.0 and implicit generation of altivec instructions when -mcpu=970. The problem is that the kernel cannot afford to use altivec instructions (nor FPU) except in controlled environment. Specifically, things like the RAID6 code has altivec (and SSE/2, which

Re: Inlining and estimate_num_insns

On Feb 27, 2005, at 5:30 PM, Steven Bosscher wrote: Interesting. You of course know Gaby is always claiming the exact opposite: That the compiler must *honor* the inline keyword (explicit or "implicit", ie. inline in class definitions), that inline is not a hint but an order that the compiler must

Re: Inlining and estimate_num_insns

On Sunday 27 February 2005 23:14, Richard Guenther wrote: > While in theory this could work well, existing code-bases (such as > POOMA) are notoriously bad in consistently using "inline" (or not). > I > guess such scheme would work great for most C people, as C people > generally think twice before

Re: Inlining and estimate_num_insns

On Sun, 27 Feb 2005 14:23:37 -0800, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Richard Guenther wrote: > > >> 5. However, it really might be sensible to have the C++ front end > >> treat "inline" as a command, rather than a hint, by default. It might > >> be that explicit uses of inline should be

Re: Inlining and estimate_num_insns

Richard Guenther wrote: 5. However, it really might be sensible to have the C++ front end treat "inline" as a command, rather than a hint, by default. It might be that explicit uses of inline should be pretty much unconditionally honored. (I'd say that functions defined in a class, but not mark

Re: Inlining and estimate_num_insns

Mark Mitchell wrote: 3. Richard's attempt to discount stuff from being counted unnecessarily in return statements makes sense to me. I shifted from avoiding duplicated counting here and there to the goal that the inliner should not pessimize abstraction by indirection, that is, the accounted size

Re: Inlining and estimate_num_insns

A few top-level comments on this thread: 1. The C++ community has split into two sub-communities. One is very heavily focused on template metaprogramming. The other is doing more "traditional" object-oriented programming. The kinds of programs written by these two communities are drastically

Re: AMD64. sign extension correct?

Claus-Justus Heine <[EMAIL PROTECTED]> writes: > 3. > (signed long) = (signed int) x (unsigned int) > > Surprisingly the sign is not promoted in this case: > > a = -1 * 20, then a = 0x ffec > > > IMHO, this is a bug. No, it's correct. The type of the multiplication expression is un

Re: Extension compatibility policy

On Feb 27, 2005, at 12:56 PM, Mike Hearn wrote: Are these compatibility patches available in discrete diff form anywhere? No. The branch's name is apple-ppc-branch, and changes are marked as APPLE LOCAL.

Re: AMD64. sign extension correct?

Claus-Justus Heine <[EMAIL PROTECTED]> writes: > (signed long) = (signed int) x (unsigned int) > > Surprisingly the sign is not promoted in this case: > > a = -1 * 20, then a = 0x ffec > > IMHO, this is a bug. No, it isn't. In this context, -1 is converted to unsigned, yielding 0xff

AMD64. sign extension correct?

Hi, I'm not subscribed, so if you want to reach me directly you have to send an email directly to me; otherwise I'll pick up any answer via the web-archives. I'm a little bit confused w.r.t. to signed/unsigned multiplication on x86_64: Assume multiplying (signed 1. (signed long) = (signed int)

Re: Extension compatibility policy

On Sun, 2005-02-27 at 08:21 -0800, Dale Johannesen wrote: > Current patches of this nature include the inclusion of strict- > aliasing in -O2, writable strings, and casts as lvalues, and I'm sure > there are others. (So if you really want any of those, you can pick > it up from Apple's branch:) I

Re: Extension compatibility policy

On Feb 27, 2005, at 6:32 AM, Joseph S. Myers wrote: And in that case we did consider users: although the concatenation of __FUNCTION__ wasn't documented, it emitted a deprecation warning in the 3.0, 3.1/3.2 and 3.3 release series before being removed in 3.4. But, you'll agree that this is an except

XPASS: 26_numerics/cmath/c99_classification_macros_c.cc

Already many weeks I see at FreeBSD 5.3 when run gcc testsuite line: XPASS: 26_numerics/cmath/c99_classification_macros_c.cc (test for excess errors) Can be XFAIL marker removed for FreeBSD 5.* (or FreeBSD 5.3 and later) --- c99_classification_macros_c.cc Tue Jun 22 14:50:46 2004 +++ c99_classifi

gcc-4.1-20050227 is now available

Snapshot gcc-4.1-20050227 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050227/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 CVS branch with the following options: -D2005-02-27 17:43 UTC You'll

Re: Inlining and estimate_num_insns

Jan Hubicka <[EMAIL PROTECTED]> writes: [...] | Basically we need to explain inliner that the abstraction functions are | free to get sane results on C++... \o/ [...] | The only problem with common heuristics I see is that in C the "inline" | keyword is very strong hint basically meaning

Re: Inlining and estimate_num_insns

> How do you suppose we fix the three-fold run-time performance > regressions I and other people see for their scientific code? right! in other words, do you want 4.0 to be a developer-only release, or do you want anyone to use it to compile actual applications? at least in my world, compilers

Re: SVN plans update

On 2005-02-26, at 19:53, Daniel Berlin wrote: In the next week, i'll be posting a test repo with all tags but snapshots and the 3 tags with rtag -F issues. Just a few words of encouragement: Keep up the fine work! More cancellation points have been added for those who have complained about ctrl-c n

Re: Inlining and estimate_num_insns

Jan Hubicka wrote: Or have different inlining heuristics for C++. I tend to thing that common heuristics smart enought to catch C++ abstraction should do fine for both. Inlining is hitting us before each release, now imagine twice as many arugments here! The only problem with common heuristics I

Re: Inlining and estimate_num_insns

> On Sunday 27 February 2005 14:58, Jan Hubicka wrote: > > > >is a problem for a few people, but if you look at the performance > > > >numbers of things like SPEC, CSiBE, and MySQL, there doesn't appear > > > >to be any performance problem. But your patch will probably still > > > >blow compile ti

Re: Inlining and estimate_num_insns

> Richard Guenther writes: >... I also think our in-lining limits are way too high, > at least unnecessary high with the patch applied... - If function-call overhead could be more accurately estimated, possibly by enabling the inclusion of set/move instructions in rtl cost estimates to

Re: Extension compatibility policy

On Feb 26, 2005, at 11:40 PM, Eric Botcazou wrote: Then somebody notices the breakage and complains about it, and sometimes even writes a patch to undo the breakage (typically an Apple employee, because Apple is legitimately concerned about backwards compatibility). Yes. Often what happens is

Re: Inlining and estimate_num_insns

Steven Bosscher wrote: On Sunday 27 February 2005 14:58, Jan Hubicka wrote: is a problem for a few people, but if you look at the performance numbers of things like SPEC, CSiBE, and MySQL, there doesn't appear to be any performance problem. But your patch will probably still blow compile time thro

Re: Extension compatibility policy

Joseph S. Myers wrote: And in that case we did consider users: although the concatenation of __FUNCTION__ wasn't documented, it emitted a deprecation warning in the 3.0, 3.1/3.2 and 3.3 release series before being removed in 3.4. Fair enough. I think it is useful to include documentation in a cle

Re: Extension compatibility policy

On Sun, 27 Feb 2005, Robert Dewar wrote: > Joseph S. Myers wrote: > > > In the case mentioned of __FUNCTION__ concatenation, (a) __FUNCTION__ was > > always documented as a variable, so concatentation of it was always > > undocumented and so liable to removal at any time > > Yes, that's a legall

Re: Inlining and estimate_num_insns

Steven Bosscher wrote: On Sunday 27 February 2005 14:58, Jan Hubicka wrote: is a problem for a few people, but if you look at the performance numbers of things like SPEC, CSiBE, and MySQL, there doesn't appear to be any performance problem. But your patch will probably still blow compile time thro

Re: Extension compatibility policy

Joseph S. Myers wrote: In the case mentioned of __FUNCTION__ concatenation, (a) __FUNCTION__ was always documented as a variable, so concatentation of it was always undocumented and so liable to removal at any time Yes, that's a legally sustainable position, just as it would be sustainable to mak

Re: Inlining and estimate_num_insns

Jan Hubicka wrote: To just add another data-point, metaprograms like the following are very common. Consider template struct Add { static inline int doit(int *x) { return Add::doit(x)+x[i]; } }; template <> struct Add<0> { static inline int doit(int *x)

Re: Inlining and estimate_num_insns

On Sunday 27 February 2005 14:58, Jan Hubicka wrote: > > >is a problem for a few people, but if you look at the performance > > >numbers of things like SPEC, CSiBE, and MySQL, there doesn't appear > > >to be any performance problem. But your patch will probably still > > >blow compile time through

Re: Extension compatibility policy

Long term, gcc extensions mean a given piece of code will only be compilable by gcc. If the extension is succesful enough, it may even be adopted by other compilers, such as Intel CC. Happened in the past. Personally, I tend to not like gcc extensions. Especially the silent variety. Now that the C

Re: Inlining and estimate_num_insns

> To just add another data-point, metaprograms like the following are very > common. Consider > > template > struct Add > { > static inline int doit(int *x) > { > return Add::doit(x)+x[i]; > } > }; > template <> > struct Add<0> > { > static inline

Re: Inlining and estimate_num_insns

> Steven Bosscher wrote: > >On Sunday 27 February 2005 10:57, Richard Guenther wrote: > > > >>Steven Bosscher wrote: > >> > >>>On Feb 27, 2005 02:04 AM, Richard Guenther > > > ><[EMAIL PROTECTED]> wrote: > > > In the end we surely want to watch CiSBE and SPEC testers. > >>> > >>>Maybe so, but

How to choose reasonable default inlining limits?

Hi! As you may have noticed I'm at changing estimate_num_insns and getting compile time regressions this way. Of course. How do/did we choose the current default inlining limits in the params.def file? While code size estimates from 3.4 to 4.0 changed quite drastically, only one of the inlining

Re: IA64 record alignment rules, and modes?

"Gary Funck" <[EMAIL PROTECTED]> writes: > typedef struct sptr_struct > { > long unsigned int phase: 48; > short unsigned int thread: 16; > void *addr; > } sptr_t; > > is assigned a BLKmode rather a TImode, [...] > > Question: If we assume that a TImode would've been a more efficien

Re: GCC 4.1 Projects

Mark Mitchell wrote: Nathan Sidwell wrote: You've not included the completion of gcc_assertification, did you miss that email, or did you not think it necessary to add it as a specific project, or ... ? The former; I thought we'd corresponded about that previously? It seemed like something that

Re: Extension compatibility policy

On Sun, 27 Feb 2005, Eric Botcazou wrote: > > In cases where breaking sources lets you achieve greater performance or > > efficiency, please do make the change but offer a switch to disable it and > > let the old code still compile. This way we it seems everybody can be > > happy. > > My impressi

Re: Inlining and estimate_num_insns

To just add another data-point, metaprograms like the following are very common. Consider template struct Add { static inline int doit(int *x) { return Add::doit(x)+x[i]; } }; template <> struct Add<0> { static inline int doit(int *x) {

Re: Inlining and estimate_num_insns

I take it as a lame property of our current inlining heuristics and function size estimate that for inline int foo { return 0; } int bar { return foo(); } the size estimate of foo is 2, that of bar is initially 13 and 5 after inlining. 3.4 did better in that it has 1 for foo, 12 for bar before

Re: Mainline java is broken

On Saturday 26 February 2005 20:45, Steven Bosscher wrote: > Mainline java is broken: > ./.libs/libgcj0_convenience.a(Logger.o)(.text+0x620): In function > `java::util::logging::Logger::getName()': > /abuild/gcc-test/gcc/libjava/java/util/logging/Logger.java:510: multiple > definition of `java::uti

Re: Extension compatibility policy

Eric Botcazou wrote: Generally speaking, this occurs as follows: a patch happens to break an extension because GCC has (had?) so many extensions that it is nearly impossible to foresee all the side-effects a patch will have on them. Then somebody notices the breakage and complains about it, and

Re: Inlining and estimate_num_insns

Steven Bosscher wrote: On Sunday 27 February 2005 10:57, Richard Guenther wrote: Steven Bosscher wrote: On Feb 27, 2005 02:04 AM, Richard Guenther <[EMAIL PROTECTED]> wrote: In the end we surely want to watch CiSBE and SPEC testers. Maybe so, but your timings already show this is pretty unacceptab

Re: Inlining and estimate_num_insns

On Sunday 27 February 2005 10:57, Richard Guenther wrote: > Steven Bosscher wrote: > > On Feb 27, 2005 02:04 AM, Richard Guenther <[EMAIL PROTECTED]> wrote: > >>In the end we surely want to watch CiSBE and SPEC testers. > > > > Maybe so, but your timings already show this is pretty unacceptable. >

Re: Inlining and estimate_num_insns

> Steven Bosscher wrote: > >On Feb 27, 2005 02:04 AM, Richard Guenther > ><[EMAIL PROTECTED]> wrote: > > > >>In the end we surely want to watch CiSBE and SPEC testers. > > > > > >Maybe so, but your timings already show this is pretty unacceptable. > > Well, the compile time regressions are not ca

Re: Inlining and estimate_num_insns

On Sun, 27 Feb 2005 02:04:19 +0100, Richard Guenther <[EMAIL PROTECTED]> wrote: > Steven Bosscher wrote: > > On Saturday 26 February 2005 23:03, Jan Hubicka wrote: > > > >>Mark? I would say that there is little risk in this patch corectness > >>wise, might have negative effect on compilation times

Re: Inlining and estimate_num_insns

Steven Bosscher wrote: On Feb 27, 2005 02:04 AM, Richard Guenther <[EMAIL PROTECTED]> wrote: In the end we surely want to watch CiSBE and SPEC testers. Maybe so, but your timings already show this is pretty unacceptable. Well, the compile time regressions are not caused by my patch but only expos