Re: Ada subtypes and base types
On Fri, 2006-03-17 at 12:51 -0700, Jeffrey A Law wrote:
> I'm not suggesting the FEs deduce more types and track ranges;
> that would be rather absurd. What I'm saying is that exposing
> these types outside the FE is most likely costing you both on
> the compile-time side and on the run-time side.
About optimization, in most languages with array bounds and
range checks, the FE will build a structure with bounds
and code like the following for a typical array loop (sorry
for poor C):
struct {
int low,high; /* no alias */
double *data;
} X;
int first_i=X.low+2;
int last_i=X.high-3;
int i;
if (first_i<=last_i) {
for(i=first_i;i<=last_i;i++) {
if (iX.high) raise_bound_error(); /* CHECK */
do_something(array_with_bounds[i]);
}
}
The interesting thing performance wise would be to be able to remove the
CHECK in the BE.
Is there some optimization pass able to do that?
And when "+2" and "-3" are replaced by "+x" and "-y" and we
know through typing that x>=0 and y>=0?
Laurent
for getting millisecond resolution in profiling with -pg option
Hi, I want to profile an application in linux. I used -pg option and profiled the data with gprof. Here I am getting the resolution in seconds only. but I wants in terms of milliseconds and microseconds. can anybody help me. or any other options and tools available. Jayaraj philips research india
gcc-4.2-20060318 is now available
Snapshot gcc-4.2-20060318 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060318/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 112202 You'll find: gcc-4.2-20060318.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20060318.tar.bz2 C front end and core compiler gcc-ada-4.2-20060318.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20060318.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20060318.tar.bz2 C++ front end and runtime gcc-java-4.2-20060318.tar.bz2 Java front end and runtime gcc-objc-4.2-20060318.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20060318.tar.bz2The GCC testsuite Diffs from 4.2-20060311 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 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.
New brach 'yara-branch' is created
I've created a branch for my allocator project which is called Yet
Another Register Allocator (or YARA - yet another recursive acronim).
I am think I reached the point when my work on a public branch can
be made. I am focused only on x86 right now. So YARA will work only
for x86 and probably for x86_64 for some tests (at least for SPEC).
There is no way that it will work for PPC, Itanium or other targets
for now.
I wanted to report the current state of YARA on coming gcc summit.
Unfortunately my proposal was rejected by the review committee.
Therefore I try to describe YARA briefly here to prevent questions for
me (sorry I can not spend much time on answering the questions).
1. Changes in the infrastructure in comparison with the report on
previous gcc summit.
o Copy activeness has been removed because it complicates the
implementation a lot.
o More coarse grain allocnos which is now close to store ranges (see
for example, Kolte's article load/store range analysis for global
register allocation).
o New notion CAN (set of connected allocnos) is added.
2. Currently YARA has the following passes (in the same order as they work).
o build IR (allocnos, copies, allocno-allocno conflicts,
allocno-copy conflicts).
o GVN (global value numbering) and removing conflicts for allocnos
with the same value.
o Building CANs and CAN conflicts
o optimistic and extended CAN coalescing (optional)
o Calculating register costs and classes for CAN (only classes from
class cover set are used. Cover set is a set of intersected
classes covering all register classes. The set is calculated such
way that moving between the register classes included in a cover
set class is cheaper than register-memory moves).
o Briggs CAN coloring (optimistic and biased coloring) with
optional live range splitting during coloring (it is analogous to
splitting in Chow's article about priority based coloring or
Bergner's article).
o Optional Chow's priority based coloring is implemented too but
it is practically debugged because the code is a bit worse than
one generated by Briggs coloring.
o Local allocation done on allocno level: satisfying insn constraint,
register elimination, allocno spilling. This pass does what reload
does in the current gcc.
o Coalescing on allocno level.
o Synchronization optimization (analogous to one described in ...):
redundant move removing and changing ld/st by register moves.
o RTL rewriting
YARA still uses old allocator passes (regclass and post-reload) for
some reasons but I hope finally it will not needed.
3. x86 YARA on SPEC
SPEC was tested on 3.2Ghz Pentium4 on gcc mainline as of Dec. 2005
with option -O2 -mtune=pentium4 (for base) and -O2 -mtune=pentium4
-fyara (for peak).
The results are the following: no improvement on SPECINT2000, 4-5%
improvement for SPECFP2000, code size is practically the same,
compiler 8% slower on SPECINT (in other words YARA is 2 times slower
than the current gcc allocator, SPECFP has some anomaly tests where
compiler 40% slower). You can find more info about SPEC at the email
end.
I have 3% improvement of SPECFP for x86_64 (on Intel Nocona, sorry I
have no free AMD machine and I think the results for AMD will be
worse) but I had no time to work on its improvement.
If you are interesting where YARA spend more time:
It is local allocator (about 40%) and building IR (15%). So they might
be rewritten (again).
YARA is a long project so please don't expect that it will be in main
line soon. Moreover even if YARA is successful don't expect reload
will be gone after that (all target ports are bound to reload very
tight that is what can I say after long work on the allocator).
What I am going to do in short perspective is
o work on code quality of some SPECINT tests (e.g. reload is doing
better job for crafty with many multi-registers than YARA)
o removing regressions for x86_64
o make it work for PPC and Itanium
o tuning for x86_64 (now YARA is very bad when a lot of hard registers
used in RTL that what differs x86_64 code from x86 one) and than
other platforms
o work on its speeding up
In long perspective I am going to add more passes:
o rematerialization (at least for const and bp+const that is what
reload does now).
o register pressure relief (splitting during coloring does not see
CFG well).
o Uncoalescing during splitting (for better splitting decision
during coloring).
o Chameleon intervals: instead of
M:=R0 Swap R0, R1
R0:=R1 generate Use R0
use R0 Swap R0, R1
R0:=M
o solving debug information problem (too many location where the
variable can be placed)
Estimated Estimated
Base Base Base Peak Peak Peak
BenchmarksRef Time Run Time RatioRef Time Run Time Ratio
Re: New brach 'yara-branch' is created
On Saturday 18 March 2006 17:56, Vladimir N. Makarov wrote: > I've created a branch for my allocator project which is called Yet > Another Register Allocator (or YARA - yet another recursive acronim). > > I am think I reached the point when my work on a public branch can > be made. I am focused only on x86 right now. So YARA will work only > for x86 and probably for x86_64 for some tests (at least for SPEC). > There is no way that it will work for PPC, Itanium or other targets > for now. Is this related to, and have you considered the long-term proposal for improving register allocation that was posted on the thislist a while ago? http://people.redhat.com/dnovillo/rable.pdf Paul
Re: New brach 'yara-branch' is created
Paul Brook wrote: On Saturday 18 March 2006 17:56, Vladimir N. Makarov wrote: I've created a branch for my allocator project which is called Yet Another Register Allocator (or YARA - yet another recursive acronim). I am think I reached the point when my work on a public branch can be made. I am focused only on x86 right now. So YARA will work only for x86 and probably for x86_64 for some tests (at least for SPEC). There is no way that it will work for PPC, Itanium or other targets for now. Is this related to, and have you considered the long-term proposal for improving register allocation that was posted on the thislist a while ago? http://people.redhat.com/dnovillo/rable.pdf Some code might be used for this proposal (especially local allocator that is what reload does. Because I hope it is easier understand than reload. Although i should say that reload is much more superior for now). But generally speaking it is a different project. I think the more projects for allocator exist, the better it is for gcc. I believe that improvement of reload done by Bernd is important too. Although it is harder for me because gcc is a moving target and i see considerable improvements in reload for the last year (e.g perlbmk was 25% slower with the current gcc allocator 9 months ago and now the gap is only 10%). Vlad Vlad
Re: GCC & libtool - plans for moving to libtool 1.5?
Please Cc: me on replies. * Joseph S. Myers wrote on Sat, Mar 18, 2006 at 02:10:51AM CET: > On Fri, 17 Mar 2006, Steve Ellcey wrote: > > > So when we finally do move to a newer libtool we will move to the > > unreleased libtool main line? I guess I was assuming we would move to a > > Yes, unless we decide to audit local changes (since libtool 2.0 branched) Forget about CVS branch-2-0. The next stable non-1.5.x Libtool release will come from what currently is CVS HEAD. (1.5 will see at least one more release because of a few regressions in 1.5.22.) > for those not on libtool 2.0 branch and use 2.0 branch with some > backported patches. I don't think using 1.5 branch will be a plausible > option. I don't know what upstream libtool policy is on what patches can > go on 2.0 branch. branch-2-0 as in CVS is dead and will not see any further changes, nor will it ever see a release. Cheers, Ralf
Re: FSF Policy re. inclusion of source code from other projects in GCC
Mark Mitchell wrote: My guess is that it's OK to include the Sun code, since it's in the public domain. This may just be nit-picking, but the above notice doesn't put the code into the public domain. Sun still owns the copyright of the software. Actually notices at the start of files have very little legal significance and are surely not sufficient to put something in the public domain (if someone swiped the Microsoft Power Point sources, and posted them with public domain headers, that would not put them in the public domain!) THe only way to be sure on something like this is to get a written release from Sun, signed by an appropriate corporate officer.
