Re: Fixincludes

2012-06-03 Thread Eric Botcazou
> 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

2012-06-03 Thread Jonathan Wakely
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

2012-06-03 Thread Jonathan Wakely
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

2012-06-03 Thread Jeremy Huntwork
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

2012-06-03 Thread Klaus Pedersen
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)

2012-06-03 Thread H.J. Lu
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

2012-06-03 Thread Richard Sandiford
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

2012-06-03 Thread gccadmin
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

2012-06-03 Thread NightStrike
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...

2012-06-03 Thread Ian Lance Taylor
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