Re: Fixincludes
> There have been discussions about the need (or lack of) for this script > to run on the Linux From Scratch development list. In LFS gcc is > bootstrapped in a very confined chroot environment where the only > headers available are the Linux headers and those from glibc. What is in > question is whether it is better in our very minimal build environment > to let the script run or disable it. That's indeed a decision that needs to be made on a platform by platform basis. You can easily evaluate what the scripts does, it's only text as input and text as output. If it does nothing for your platform at a given point in time, you might want to take the risk of disabling it for the future. > After reading up further, it appears that the possibility exists that > the script may 'fix' things in the libc headers that we don't want or > need 'fixed'. I'm trying to ascertain what things the script in > particular is 'fixing' and which way is more technically sound in our > build scenario. In my experience, bugs in fixincludes are very rare. Every fix that is applied is documented in the sources. -- Eric Botcazou
Re: Fixincludes
On 3 June 2012 01:30, Jeremy Huntwork wrote: > > After reading up further, it appears that the possibility exists that the > script may 'fix' things in the libc headers that we don't want or need > 'fixed'. I'm trying to ascertain what things the script in particular is > 'fixing' and which way is more technically sound in our build scenario. It's trivial to let it run and compare the fixed files to the originals. On my system with a recent glibc I still see lots of changes to limits.h, I assume they're not pointless and are worth having.
Re: The Point
On 3 June 2012 01:46, Gmail wrote: > Lemmings, > What is the point of putting such an immense list of fragments of the manual > online? What if we loose out internet? Do you hate the thought of making one > whole file containing the whole manual available because no one else does it > that way? Are you lost in the world if you do not follow, however blindly, > after the crowd? Im sure that was your motivation. Dont even dream of trying > to validate this infantile error. > Anti-Lemming Thanks for your ill-informed, baseless email. The documentation is included with the sources and installed (in a single gcc.info file) with the compiler. If you don't want to or unable to read it online then you don't have to.
Re: Fixincludes
On Jun 3, 2012, at 7:45 AM, Jonathan Wakely wrote: > It's trivial to let it run and compare the fixed files to the > originals. On my system with a recent glibc I still see lots of > changes to limits.h, I assume they're not pointless and are worth > having. I believe that gcc always supplies an internal limits.h which usually then directly includes the system limits.h regardless of whether the fixincludes script is used or not. JH
Re: MIPS: 2'nd pass of ira, causes weird register allocation for 2-op mult
On Tue, May 29, 2012 at 6:55 AM, Vladimir Makarov wrote: > On 05/28/2012 03:09 PM, Richard Sandiford wrote: >> >> Klaus Pedersen writes: >>> >>> The summery goes something like this: >>> >>> It is possible for the second pass of ira to get confused and decide that >>> NO_REGS or a hard float register are better choices for the result of the >>> 2 operand mult. First pass already optimally allocated in >>> GR_AND_MD1_REGS. >> >> Yeah. I'm afraid this is something I've been sitting on for a while now. >> >> I think the only practical way of calculating accurate costs for things >> like GR_AND_MD_REGS really is to count the cost of the constituent classes >> and then take their MAX. >> >> Vlad, what do you think? Is the above exclude_p code "just" a >> compile-time >> speed-up? > > Yes, I think so. Every cost pass is very expensive and practically > proportional to number of classes in consideration. > > Probably, exluding some classes was a bad solution to speed IRA up. Or may > be we need the pressure classes calculation improvements. As I remember I > tried long ago to calculate IRA cover classes automatically and it did not > work. Pressure classes calculation is analgous to the cover classes > calculation but it is less critical for register pressure sensitive insn > scheduling. As a test, I tried to search all: ira-exhausive-search.patch --- gcc-4.7-20120526-orig/gcc/ira-costs.c 2012-06-03 19:01:00.861129575 +0800 +++ gcc-4.7-20120526/gcc/ira-costs.c2012-06-03 19:01:16.854081473 +0800 @@ -258,7 +258,7 @@ setup_regno_cost_classes_by_aclass (int for (i = 0; i < ira_important_classes_num; i++) { cl = ira_important_classes[i]; - if (exclude_p) + { /* Exclude no-pressure classes which are subsets of ACLASS. */ This didn't make any difference to the output (at least not with -mips1 and -O2). Probably my patch is not doing the right thing! My tree is around 1500 files, which gcc compiles into 3515246 lines of assembly. Next I disabled second pass with: ira-no_2nd_pass.patch --- gcc-4.7-20120526-orig/gcc/ira-costs.c 2012-06-03 19:01:00.861129575 +0800 +++ gcc-4.7-20120526/gcc/ira-costs.c2012-06-03 19:05:45.054289701 +0800 @@ -1537,7 +1537,8 @@ find_costs_and_classes (FILE *dump_file) use for each allocno. However, if -fexpensive-optimizations are on, we do so twice, the second time using the tentative best classes to guide the selection. */ -for (pass = start; pass <= flag_expensive_optimizations; pass++) + +pass = start; { if ((!allocno_p || internal_flag_ira_verbose > 0) && dump_file) fprintf (dump_file, This improved things a lot. 280 files changed and many had improved. My original fix, that use sane cost for the ACC_REGS: gpr_acc_cost_3.patch --- gcc-4.7-20120526-orig/gcc/config/mips/mips.c2012-06-03 19:28:02.137960837 +0800 +++ gcc-4.7-20120526/gcc/config/mips/mips.c 2012-06-03 19:31:12.587399458 +0800 @@ -11258,7 +11258,7 @@ mips_move_to_gpr_cost (enum machine_mode case ACC_REGS: /* MFLO and MFHI. */ - return 6; + return 3; case FP_REGS: /* MFC1, etc. */ @@ -11294,7 +11294,7 @@ mips_move_from_gpr_cost (enum machine_mo case ACC_REGS: /* MTLO and MTHI. */ - return 6; + return 3; case FP_REGS: /* MTC1, etc. */ This also improved things a lot. Again around 280 files changed. This got the number of generated assembly down to 3513371 (almost 2000 lines better that the original) Funny enough combining the two patches didn't bring any benefits (actually 700 lines worse) The files below had the biggest changes (in last two col's): Origno2ndpa grpcost gprcost no2ndpass xc_surface.o.s 27158 26940 26700 -458-218 xc_adpcm.o.s413739944004-133-143 xc_blit_1.o.s 419941994101-98 +0 xc_ts_calib.o.s 276 245 245 -31 -31 xc_camera.o.s 334933633321-28 +14 xc_glyph.o.s10048 10203 10027 -21 +155 xc_blit_A.o.s 10991 10851 10992 +1 -140 xc_events.o.s 714171417160+19 +0 xc_miarc.o.s16172 16317 16235 +63 +145 As can be seen - there is no clear pattern, except gpr_acc_cost_3.patch does better. But there are some cases where it is worse (the xc_miarc file), xc_blit_A is also interesting as ira-no_2nd_pass.patch improved a lot. Generally problems look like: mflo$14 sw $14,4($sp) lw $15,4($sp) mult$2,$10 (the copy in 4($sp) is never used) Strangely the 19 additional lines in xc_Events.o.s is all caused by bogus moves. Strangely because the patch only changes the cost of ACC_REGS, which is not used: addiu $4,$4,%lo(.LC0) jal dbg_AssertUtil sw $2,48($sp)
Re: GCC 4.7.1 Status Report (2012-05-30)
On Wed, May 30, 2012 at 6:08 AM, Richard Guenther wrote: > > Status > == > > The GCC 4.7 branch is in regression and documentation fixes only state. > > A release candidate for GCC 4.7.1 is scheduled for the beginning of > next week. This is a good time to verify regression status for > your favorite target and to consider to flush your pending 4.7-branch > patches list. > > As usual the number of bugs is slowly increasing. Still many serious > bugs have been fixed. > > > Quality Data > > > Priority # Change from Last Report > --- --- > P1 0 > P2 85 + 19 > P3 5 - 8 > --- --- > Total 90 + 11 > > > Previous Report > === > > http://gcc.gnu.org/ml/gcc/2012-03/msg00345.html > > The next report will be sent by me when announcing the release > candidate. Can we fix http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53539 for GCC 4.7.1? Thanks. -- H.J.
Re: MIPS: 2'nd pass of ira, causes weird register allocation for 2-op mult
Klaus Pedersen writes: > On Tue, May 29, 2012 at 6:55 AM, Vladimir Makarov wrote: >> On 05/28/2012 03:09 PM, Richard Sandiford wrote: >>> >>> Klaus Pedersen writes: The summery goes something like this: It is possible for the second pass of ira to get confused and decide that NO_REGS or a hard float register are better choices for the result of the 2 operand mult. First pass already optimally allocated in GR_AND_MD1_REGS. >>> >>> Yeah. I'm afraid this is something I've been sitting on for a while now. >>> >>> I think the only practical way of calculating accurate costs for things >>> like GR_AND_MD_REGS really is to count the cost of the constituent classes >>> and then take their MAX. >>> >>> Vlad, what do you think? Is the above exclude_p code "just" a >>> compile-time >>> speed-up? >> >> Yes, I think so. Every cost pass is very expensive and practically >> proportional to number of classes in consideration. >> >> Probably, exluding some classes was a bad solution to speed IRA up. Or may >> be we need the pressure classes calculation improvements. As I remember I >> tried long ago to calculate IRA cover classes automatically and it did not >> work. Pressure classes calculation is analgous to the cover classes >> calculation but it is less critical for register pressure sensitive insn >> scheduling. > > As a test, I tried to search all: ira-exhausive-search.patch > > --- gcc-4.7-20120526-orig/gcc/ira-costs.c 2012-06-03 19:01:00.861129575 > +0800 > +++ gcc-4.7-20120526/gcc/ira-costs.c 2012-06-03 19:01:16.854081473 +0800 > @@ -258,7 +258,7 @@ setup_regno_cost_classes_by_aclass (int >for (i = 0; i < ira_important_classes_num; i++) > { > cl = ira_important_classes[i]; > - if (exclude_p) > + > { > /* Exclude no-pressure classes which are subsets of >ACLASS. */ > > This didn't make any difference to the output (at least not with -mips1 and > -O2). Probably my patch is not doing the right thing! Yeah, the change I was talking was effectively changing "if (exclude_p)" to "if (0)", whereas the change above does the opposite. It sounds from Vlad's compile-time measurements (thanks Vlad) that this case is still important. I was wondering whether we could record cases where the best_cost calculated while working out the preferred class doesn't match the cost actually recorded in the array. I haven't had chance to try it yet though. Probably we'd want something a bit smarter than that, since subclasses of GENERAL_REGS that get combined through union would often have the same cost as the union class. The divergence would often only come when merging classes for different register sets (although of course IRA has no way of telling which those are). > My original fix, that use sane cost for the ACC_REGS: gpr_acc_cost_3.patch Why sane? Transfers from and (especially) to HI and LO really are expensive on many processors. Obviously it'd be nice at some point to make this legacy code take processor-specific costs into account, but... > --- gcc-4.7-20120526-orig/gcc/config/mips/mips.c 2012-06-03 > 19:28:02.137960837 +0800 > +++ gcc-4.7-20120526/gcc/config/mips/mips.c 2012-06-03 19:31:12.587399458 > +0800 > @@ -11258,7 +11258,7 @@ mips_move_to_gpr_cost (enum machine_mode > > case ACC_REGS: >/* MFLO and MFHI. */ > - return 6; > + return 3; > > case FP_REGS: >/* MFC1, etc. */ > @@ -11294,7 +11294,7 @@ mips_move_from_gpr_cost (enum machine_mo > > case ACC_REGS: >/* MTLO and MTHI. */ > - return 6; > + return 3; > > case FP_REGS: >/* MTC1, etc. */ ...this says that it is better to use LO as scratch space than spilling to memory -- and better by some margin -- which often isn't the case. As Vlad says, the behaviour you're seeing with the second pass isn't deliberate. The costs calculated during the first pass are generally what they're supposed to be. In particular, the cost of MD1_REG is already an accurate reflection of what I believe the costs above were supposed to achieve. The problem is that calculating the cost of "GENERAL_REGS or MD1_REG" using solely the union class is fundamentally going to give wrong results, for the reasons I mentioned earlier. That's a general problem that isn't directly related to the choice of costs (although of course artificially lowering the costs will make the problem go away in more cases). Richard
gcc-4.8-20120603 is now available
Snapshot gcc-4.8-20120603 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120603/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 188156 You'll find: gcc-4.8-20120603.tar.bz2 Complete GCC MD5=178e1a4fc0fff0f7ff6e4f7cd3d05ccd SHA1=6b4c469c13d7f4f32daf0f3967e4b78969003e14 Diffs from 4.8-20120527 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 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: Fixincludes
On Sun, Jun 3, 2012 at 1:45 AM, Jonathan Wakely wrote: > On 3 June 2012 01:30, Jeremy Huntwork wrote: >> >> After reading up further, it appears that the possibility exists that the >> script may 'fix' things in the libc headers that we don't want or need >> 'fixed'. I'm trying to ascertain what things the script in particular is >> 'fixing' and which way is more technically sound in our build scenario. > > It's trivial to let it run and compare the fixed files to the > originals. On my system with a recent glibc I still see lots of > changes to limits.h, I assume they're not pointless and are worth > having. Why not push those changes to glibc?
Re: Traversing trees in a plugin...
Brett Foster writes: > 1) How to marking a node as visited by my algorithm (without screwing > up the compiler!) Use a pointer_set. > 2) How to associate additional data (perhaps a pointer to something > else) to a node (like a unique identifier, or a pointer to a data > structure). Use a pointer_map. > b) However with types (especially those that are anonymous) I find it > challenging to do so. I assign such a node an anonymous identifier or > try to assign a general data type (i.e. integer) when the type is > internal. With types, use TYPE_CANONICAL to get the type that you should add to the pointer_set or pointer_map. I admit it gets more complicated if TYPE_CANONICAL is not appropriate for your plugin, e.g., if you need to distinguish different typedefs for the same type. > 2) Can memory addresses be used to uniquely identify nodes? I believe > this may be the case for identifier nodes. Yes. Ian