question about pass management

Hi, I have to run a pass which modifies the function types of all functions in a a C file, by adding an extra parameter to each function. If this pass runs like all other optimization passes, then this pass runs when each function is being processed. So, for a prog like this: int my_funct(in

Re: -fprofile-generate and -fprofile-use

Hello, > >A more likely source of performance degradation is that loop unrolling > >is enabled when profiling, and loop unrolling is almost always a bad > >pessimization on 32 bits x86 targets. > > To clarify, I was compiling with -funroll-loops and -fpeel-loops > enabled in both cases. > > The

Re: doloop-opt deficiency

Hello, > Dale Johannesen wrote: > > I think this is a simple pasto; this code was evidently copied from > > the previous block: > > > > I don't think that this was a simple pasto. The code looks correct. > We have the same code in tree-ssa-loop-niter.c around line 436, since > we inherited this

Re: question about pass management

if I modify the type of my_funct to take 3 args (int, int, float), then the type checker ( which runs before my pass for "main" ) bombs out saying that the call to "my_funct" has lesser than required parameters. Where should I be running this pass? The way it looks is that i need the pass manage

Re: doloop-opt deficiency

Dale Johannesen wrote: > No, look closer. The version in loop-iv.c does a NEG of 'step' just > before what's shown here. The version in tree-ssa-loop-niter.c > doesn't. Reversing the operator does make them do the same thing. Then, I think this is ok. But you'll have to ask a middle-end mainta

RE: question about pass management

Original Message >From: Paolo Bonzini >Sent: 31 August 2005 10:07 >> if I modify the type of my_funct to take 3 args (int, int, float), >> then the type checker ( which runs before my pass for "main" ) bombs >> out saying that the call to "my_funct" has lesser than required >> parameters.

mmx register moves through memory

Hi ! I've found that latest GCC versions (past 4.0.0 and up to latest in CVS head) never use 'movd %genreg, %mmxreg' to load mmx registers and always insists doing it through memory eq. 'mov %genreg, (mem)' 'movd (mem), %mmxreg' Older GCC versions do the same thing directly, without involving

Re: mmx register moves through memory

Hi, Vahur Sinijärv schrieb: > I've found that latest GCC versions (past 4.0.0 and up to latest in CVS > head) never use 'movd %genreg, %mmxreg' to load mmx registers and always > insists doing it through memory eq. > 'mov %genreg, (mem)' > 'movd (mem), %mmxreg' I haven't read entirely through you

GCC-3.4.5 status report

Hi, Despite a number of bug fixing patches applied to gcc-3_4-branch (special thanks to Richard Sandiford), the total count of bugs open against GCC-3.4.5 only has increased from 115 (last report) to 117 (this morning). That reflects a continual flux of incoming PRs for GCC-3.4.x and bugs pres

Re: mmx register moves through memory

Hi, No, the problem I wrote about is not fixed. I used GCC from CVS head 30.08.2005. I think you found a different bug, you seem to have many unneccessary uses of secondary memory between moves from MMX reg to MMX reg. The code I wrote about (in i386.c) allows direct moves between MMX regs, but p

Re: mmx register moves through memory

On 8/31/05, Vahur Sinijärv <[EMAIL PROTECTED]> wrote> Hi, > > No, the problem I wrote about is not fixed. I used GCC from CVS head > 30.08.2005. > I think you found a different bug, you seem to have many unneccessary > uses of secondary memory between moves from MMX reg to MMX reg. The code > I wr

RE: question about pass management

On Wed, 2005-08-31 at 10:50 +0100, Dave Korn wrote: > Original Message > >From: Paolo Bonzini > >Sent: 31 August 2005 10:07 > > >> if I modify the type of my_funct to take 3 args (int, int, float), > >> then the type checker ( which runs before my pass for "main" ) bombs > >> out saying th

Re: GCC-3.4.5 status report

On Wed, 2005-08-31 at 12:42, Gabriel Dos Reis wrote: > rtl-optimization: 20 > 17810 internal compiler error: in verify_local_live_at_start for > arm-rtems, arm-linux This is a dup of 15342. I'm just testing a back-port of the fix to the 3.4 branch. R.

Improved aliasing branch todo list

I've put the current todo list (at least, my todo list) for the improved-aliasing branch up on the wiki. http://gcc.gnu.org/wiki/Improved%20Aliasing%20Todo%20List

Re: -fprofile-generate and -fprofile-use

>you may try adding -fmove-loop-invariants flag, which enables new >invariant motion pass. That cleaned up both my simplified test case, and the code it originated from. It also cleaned up a few other cases where I was noticing worse performance with FDO enabled. Thanks!! Perhaps this option sh

Re: GCC-3.4.5 status report

Just to let you know (to avoid duplicate work): There are several C++ bugs assigned to Mark which he already fixed on mainline and the 4.0 branch. Since he's busy with 4.0/4.1 regressions, I'll try to backport (at least some of) the patches back to the 3.4 branch. (He agreed to that plan in privat

Re: mmx register moves through memory

On Wed, Aug 31, 2005 at 02:23:03PM +0300, Vahur Sinijärv wrote: > So, my question is: Should this requirement of using secondary memory to > move MMX registers between general regs be relaxed ? No. > I do not see the point why you should discourage the register allocator > from using mmx regist

Re: mmx register moves through memory

I filed a bug #23660: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23660 Regards, Vahur Richard Guenther wrote: On 8/31/05, Vahur Sinijärv <[EMAIL PROTECTED]> wrote> Hi, No, the problem I wrote about is not fixed. I used GCC from CVS head 30.08.2005. I think you found a different bug, you s

Re: GCC testsuite timeout question (gcc.c-torture/compile/20001226-1.c)

> > By hand, I can compile the test in about 3 1/2 minutes on the machine in > > question (the machine may have been busier when the failure occured and thus > > taken longer). > > I think it's a real regression (memory consumption/speed) of the compiler, it > is timing out on all the slow SPARC

Running ranlib after installation - okay or not?

We currently perform the following sequence of commands as part of the installation (-m 444 being the default on current FreeBSD systems). install -m 444 ./libgcc.a /prefix/lib/gcc/i386-portbld-freebsd5.4/3.4.5/gcc/i386-portbld-freebsd5.4/3.4.5/ ranlib /prefix/lib/gcc/i386-portbld-freebsd5.

Re: Running ranlib after installation - okay or not?

Gerald Pfeifer <[EMAIL PROTECTED]> writes: > We currently perform the following sequence of commands as part of the > installation (-m 444 being the default on current FreeBSD systems). > > install -m 444 ./libgcc.a > /prefix/lib/gcc/i386-portbld-freebsd5.4/3.4.5/gcc/i386-portbld-freebsd5.4/3

Re: Running ranlib after installation - okay or not?

ranlib is required on Darwin after changing the timestamp of the archive. Shantonu On Aug 31, 2005, at 11:02 AM, Ian Lance Taylor wrote: Gerald Pfeifer <[EMAIL PROTECTED]> writes: We currently perform the following sequence of commands as part of the installation (-m 444 being the defaul

Re: Running ranlib after installation - okay or not?

On Aug 31, 2005, at 2:02 PM, Ian Lance Taylor wrote: Gerald Pfeifer <[EMAIL PROTECTED]> writes: Does anyone disagree (and if not, have suggestions how to address this in GCC)? ranlib is basically never required on a modern system. It is really only needed if the archive is built with the S

Re: GCC-3.4.5 status report

Volker Reichelt <[EMAIL PROTECTED]> writes: | Just to let you know (to avoid duplicate work): | | There are several C++ bugs assigned to Mark which he already | fixed on mainline and the 4.0 branch. Since he's busy with 4.0/4.1 | regressions, I'll try to backport (at least some of) the patches |

Re: Running ranlib after installation - okay or not?

On Wed, Aug 31, 2005 at 02:15:46PM -0400, Andrew Pinski wrote: > > On Aug 31, 2005, at 2:02 PM, Ian Lance Taylor wrote: > > >Gerald Pfeifer <[EMAIL PROTECTED]> writes: > > > >>Does anyone disagree (and if not, have suggestions how to address this > >>in GCC)? > > > >ranlib is basically never requ

Re: GCC testsuite timeout question (gcc.c-torture/compile/20001226-1.c)

> Yes, I think you are right. I can see a substantial slowdown in > compilation times on IA64 HP-UX at -O2 (though it doesn't time out > there). > > gcc 4.0.0 - 81 seconds > gcc 3.4.1 - 38 seconds > gcc 3.4.0 - 37 seconds > gcc 3.3.5 - 89 seconds > gcc 3.3.1 - 91 seconds > > 3.3 is slow, 3.4 is fa

Re: mmx register moves through memory

Richard Henderson wrote: I do not see the point why you should discourage the register allocator from using mmx registers, move through memory is clearly inefficent and enlarges resulting code (if the function containing moves is inlined in several places, even more so). First, what you

Re: Running ranlib after installation - okay or not?

Andrew Pinski <[EMAIL PROTECTED]> writes: > On Aug 31, 2005, at 2:02 PM, Ian Lance Taylor wrote: > > > Gerald Pfeifer <[EMAIL PROTECTED]> writes: > > > >> Does anyone disagree (and if not, have suggestions how to address this > >> in GCC)? > > > > ranlib is basically never required on a modern sy

Re: GCC-3.4.5 status report

Installed. Gerald Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.514 diff -u -3 -p -r1.514 index.html --- index.html 24 Aug 2005 19:04:13 - 1.514 +++ index.html 31 Aug 2005 19:24

Re: Running ranlib after installation - okay or not?

Ian Lance Taylor writes: > Andrew Pinski <[EMAIL PROTECTED]> writes: > > > On Aug 31, 2005, at 2:02 PM, Ian Lance Taylor wrote: > > > > > Gerald Pfeifer <[EMAIL PROTECTED]> writes: > > > > > >> Does anyone disagree (and if not, have suggestions how to address this > > >> in GCC)? > > > > > > ra

[gfortran] Change language name from "f95" to "fortran"

Attached patch changes the name of the language in --enable-languages from "f95" to "fortran", and in a few other places. There are still lots of places which are refered to as f95 (such as f951 ;-), but they are all internal uses. I'm not very familiar with the mechanism of language names, so

Re: Running ranlib after installation - okay or not?

On Wed, 31 Aug 2005, Ian Lance Taylor wrote: ranlib is basically never required on a modern system. It is really only needed if the archive is built with the S option to ar. >>> If you consider Darwin "modern", then that statement is not correct >>> as moving/copying an archive on darwin

Re: -fprofile-generate and -fprofile-use

I do not see this flag in gcc3.4.4. perflab2% gcc -o conftest -O3 -march=pentium4 -fmove-loop-invariants conftest.c cc1: error: unrecognized command line option "-fmove-loop-invariants" Am I missing something? -girish --- Zdenek Dvorak <[EMAIL PROTECTED]> wrote: > Hello, > > > >A more likel

Re: -fprofile-generate and -fprofile-use

On Aug 31, 2005, at 3:40 PM, girish vaitheeswaran wrote: I do not see this flag in gcc3.4.4. Am I missing something? you may try adding -fmove-loop-invariants flag, which enables new invariant motion pass. The "new invariant motion pass". -eric

Re: Successfull gcc-3.4.4 build on hppa1.1-hp-hpux10.20

> Used full distribution + make bootstrap. Used egcs-2.91.57 and > binutils-2.11.2 to compile gcc. If you are interested in much improved C++ support, upgrade binutils to 2.16 or later and rebuild GCC with the new binutils. This provides one-only support under HP-UX 10.20. You also need the lat

Re: Running ranlib after installation - okay or not?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gerald Pfeifer wrote: |> |>Except that probably this has to get into libtool somehow or |>something. Hmmm. | | | Ouch, now you got me scared. I already started testing a patch to remove | the ranlib invocations that are part of the installation, but

Re: Running ranlib after installation - okay or not?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter O'Gorman wrote: | The problem is that libtool tries to run ranlib after install and that | ranlib can fail if the library is not writable? [crosspost - beware - for context see ] When I look mor

Re: Successfull gcc-3.4.4 build on hppa1.1-hp-hpux10.20

On Wed, 31 Aug 2005, John David Anglin wrote: Used full distribution + make bootstrap. Used egcs-2.91.57 and binutils-2.11.2 to compile gcc. If you are interested in much improved C++ support, upgrade binutils to 2.16 or later and rebuild GCC with the new binutils. This provides one-only supp