Re: Constant folding and Constant propagation

[Paolo Bonzini]

Jean Christophe Beyler wrote:
> Ok, thanks for all this information and if you can dig that up it
> would be nice too.  I'll start looking at that patch and PR33699 to
> see if I can adapt them to my needs.

Here it is.

Paolo
/* Copy propagation on RTL for GNU compiler.
   Copyright (C) 2006 Free Software Foundation, Inc.

This file is part of GCC.

GCC is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free
Software Foundation; either version 2, or (at your option) any later
version.

GCC is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
for more details.

You should have received a copy of the GNU General Public License
along with GCC; see the file COPYING.  If not, write to the Free
Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301, USA.  */

#include "config.h"
#include "system.h"
#include "coretypes.h"
#include "tm.h"
#include "rtl.h"
#include "obstack.h"
#include "basic-block.h"
#include "insn-config.h"
#include "recog.h"
#include "alloc-pool.h"
#include "timevar.h"
#include "tree-pass.h"

/* The basic idea is to keep a table of registers with the same
   value, and replace expressions encountered so that they use the
   equivalent register.  We do this processing on extended basic
   blocks.

   Note this can turn a conditional or computed jump into a nop or
   an unconditional jump.  This is left to be cleaned up by CSE,
   for now.

   At the start of each basic block, an assignment places a register
   in a distinct group number.  During scan, when the code copies
   one register (or a related expression, see below) into another, we
   copy the quantity number.  When a register is loaded in any other
   way, we allocate a new quantity number to describe the value
   generated by this operation. `reg_group[regno].num' records what
   quantity register REGNO is currently thought of as containing.

Other expressions:

   A CLOBBER rtx in an instruction invalidates its operand for further
   reuse.

Related expressions:

   Registers that differ only by an additive integer are called related.
   Related registers share the same quantity number.  */


/* Per-group information tracking.  */
struct group_table_elem
{
  rtxreg;
  HOST_WIDE_INT  delta;

  /* Basic block in which it was defined.  */
  basic_blockbb;

  struct group_table_elem *prev, *next;
};

/* Per-register data, including register->group mapping.  */
struct reg_data
{
  /* Current group.  */
  struct group_table_elem *entry;

  /* Pointer into the table of group heads, indexed by register number.
 Always 0 for unknown values.  */
  int  num;
};


/* Length of group_head vector.  */
static int max_group;

/* Next quantity number to be allocated.
   This is 1 + the largest number needed so far.  */
static int next_group;

/* The table of all groups, indexed by group number.  */
static struct group_table_elem **group_head;


/* The table of all pseudos, indexed by regno.  */
static struct reg_data *reg_group;


/* Allocation pool.  */
static alloc_pool group_elem_pool;

/* Basic block being processed.  */
static basic_block current_bb;


/* We store the state of each basic block (not visited, part of current EBB,
   finished) in its AUX field.  These two functions return the state.  */

static inline bool
bb_visited (basic_block bb)
{
  return bb->aux != 0;
}

static inline bool
bb_active (basic_block bb)
{
  return bb->aux == (void *) 1L;
}


/* Routines to manage the data structures of this pass.  */

/* Remove the register DEST from the equivalence tables.  */

static struct group_table_elem *
remove_from_group (rtx dest)
{
  struct group_table_elem *ent = reg_group[REGNO (dest)].entry;
  int num = reg_group[REGNO (dest)].num;

  reg_group[REGNO (dest)].num = 0;
  reg_group[REGNO (dest)].entry = NULL;

  gcc_assert (ent);
  if (ent->prev)
ent->prev->next = ent->next;
  else
group_head[num] = ent->next;

  if (ent->next)
ent->next->prev = ent->prev;

  ent->prev = ent->next = NULL;
  return ent;
}



/* Check if the entry for register REG in the equivalence tables is up to date.
   Remove it and return NULL if it is not.  Otherwise, return the entry, or NULL
   if it is absent.  */

static inline struct group_table_elem *
reg_group_entry (rtx reg)
{
  struct group_table_elem *ent = reg_group[REGNO (reg)].entry;
  if (ent && !bb_active (ent->bb))
{
  remove_from_group (reg);
  return NULL;
}
  else
return ent;
}


/* Return the head of the equivalence class for REG (removing stale entries).  
*/

static struct group_table_elem *
reg_group_head (rtx reg)
{
  int num = reg_group[REGNO (reg)].num;

  struct group_table_elem *canon_ent = group_head[num];
  while (canon_ent && !bb_active (canon

Re: proposal for improved management bugzilla priorities/release criteria

[Richard Guenther]

On Fri, Feb 6, 2009 at 5:30 PM, Paolo Bonzini  wrote:
> The current system for managing bugzilla priorities has a major problem,
> in that it does not identify bugs that reasonably cannot be fixed before
> the release.
>
> The current set of priorities is in practice like this:
>
> - P1: most wrong code bugs, and other absolutely blocking problems
> - P2: problems worth a look on important platforms
> - P3: uncategorized
> - P4: problems worth a look on less important platforms
> - P5: other
>
> The problem with this set is that while P1 bugs will absolutely be fixed
> before the release (and backported usually), P2 bugs are a one-catch-all
> group for everything else that's worth looking at.  It is impossible to
> distinguish stuff that will probably be fixed before the release (and
> presumably backported to all branches), and what instead requires new
> stage1/stage2 material.
>
> As a result, the release criteria we have are not really a measure of
> the quality of the release, and especially are not really a measure of
> the work being done towards a release.

I also experience it as limiting that for "important" regressions we only
have P1 and P2 (P3 counts as un-prioritized, so isn't available).

> I propose two solutions to this problem.
>
> - The more conservative one is to use more aggressively the release
> milestone field.  Hard-to-fix bugs would be left as P2, but bumped to
> the next major release at the beginning of stage 3.
>
> Advantages: no need for churn in the bug database---very easy to implement
> Disadvantages: the milestone field is not visible in search lists (maybe
> this can be changed)?

I think using the milestone will get us more confused only.  We already
have the issue that what we make a blocker (P1) for 4.4 is not a blocker
for, say, 4.3.4.  Unless we want to start duplicating bugs for each open
branch I'd rather not touch our target milestone policy.

> - Alternatively, we could add a new priority "P--" for uncategorized
> bugs, and split P2/P3 like this: P2 bugs will be fixed in stage 3/4, P3
> bugs will most likely be postponed to stage 1/2.
>
> Advantages: quicker impression from the bug searches, especially during
> bug triage
> Disadvantages: need to rethink bugzilla queries

We can simply rename the existing P3 to -- (I like no leading P) and add
a new priority P3.  -- would be the new default then.

P3 would then be used for important regressions that do not qualify
for fixing during "stage4" (which includes release branches).  The
advantage over downgrading them from P2 to P4 at the start of
stage4 would be that the distinction is visible earlier and so people
who care can pick ones they find important and make sure they get
fixed before stage4.

> I think any of these two approaches would provide a serious added value
> to judging a release quality.  Meeting the release criteria ("no more
> than 50 P2 regressions") in the past included the release managers
> downgrading bugs from P2 to P4, which is in my opinion cheating.  In the
> proposed scheme, this would be less necessary, because the release
> criteria could take into account a broader view, such as respectively
> for the two approaches:
>
> - At most 60 P2 regressions, of which at most 15 should have release
> milestone 4.4.0.
>
> - No more than 15 P2 regressions and 45 P3 regressions.

I think the only reasonable release criteria is zero P1 regressions over
some period.  50 P2 regressions doesn't make a release blocker, neither
is 49 P2 regressions a clear sign for a non-blocked release.

Richard.

> Any opinions?
>
> Paolo
>
>

Re: Closing 4.2 branch

[Gerald Pfeifer]

On Wed, 4 Feb 2009, Mark Mitchell wrote:
> > This means disabling snapshots and nightly DATESTAMP updates for the 
> > branch, closing bugs that are open as 4.2 regressions but fixed in 
> > 4.3, 4.4 and 4.5, and removing "4.2/" from the summaries of 4.2 
> > regression bugs that remain open as also being regressions in future 
> > releases.
> Let's add a checklist for that as well; it's a mechanical process that 
> we may as well document.

I'll be happy to reformat/whatever a raw such checklist and put it
online, or help as things are related to snapshots.

Gerald

RE: [plugins] Branch for plugins development created

[Grigori Fursin]

Hi Diego, et al,

As Sebastian mentioned INRIA finally signed copyright transfer form
for FSF last year so our patches can be easily integrated into GCC.

During this week, I will check the current GCC plugins branch and will send you 
more
info about the current version of Interactive Compilation Interface
to see how we can help with the developments and what we can reuse 
for the GCC plugins (we are naturally interested to test and extend this branch
to simplify further ICI developments). I am working with Zbigniew Chamski and 
Cupertino Miranda to extend ICI so I put them in CC.

The current version of ICI is actually synchronized with the latest GCC trunk,
has a very small code-base and touches minimal parts of the compiler - 
it have been used in various projects
within last 5-6 months to select optimization passes or change their orders
per function to optimize performance/code-size for programs and Linux libraries
at ARC, IBM and STMicro or test the new local releases of a compiler and 
instrument
program for further analysis. I need to look through all the feedback we got 
from our users to update the Plugins Wiki with the practical 
usage scenarios and different plugins we developed - I will try to 
do it within next few days and will check the proposed GCC plugins API 
to sync with ICI...

Take care and have a good week,
Grigori
 


> -Original Message-
> From: Diego Novillo [mailto:dnovi...@google.com]
> Sent: Friday, February 06, 2009 9:49 PM
> To: gcc@gcc.gnu.org
> Cc: Sean Callanan; Taras Glek; Le-Chun Wu; Basile STARYNKEVITCH; Grigori 
> Fursin; Gerald
> Pfeifer
> Subject: [plugins] Branch for plugins development created
> 
> I have created the plugins branch (rev. 143989).  As I offered before,
> I will help maintain the branch synchronized with mainline and with
> patch reviews.  The branch can be checked out with
> 
> $ svn co svn://gcc.gnu.org/svn/gcc/branches/plugins
> 
> As usual, I created a wiki page for the branch
> (http://gcc.gnu.org/wiki/plugins) and patched svn.html to document the
> branch.
> 
> Before I can accept patches, however, I need to make sure that
> everyone has copyright assignments on file.  I know that Taras, Basile
> and Le-Chun do.  Sean and Grigori, do you folks have copyright papers
> already?
> 
> I understand that Le-Chun has an initial patch for the branch based on
> the API we've been discussing.  If everyone agrees, I will review that
> for inclusion.
> 
> Gerald, is this patch to svn.html OK?  I see that there are some stale
> entries in there.  I'll clean them up with a follow-up patch.
> 
> 
> Thanks.  Diego.
> 
> Index: htdocs/svn.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/svn.html,v
> retrieving revision 1.109
> diff -d -u -p -r1.109 svn.html
> --- htdocs/svn.html 9 Dec 2008 15:27:03 -   1.109
> +++ htdocs/svn.html 6 Feb 2009 20:40:35 -
> @@ -391,6 +391,11 @@ the command svn log --stop-on-copy
>DWARF-4 is currently under development, so changes on this branch
>will remain experimental until Version 4 is officially finalized.
> 
> +  plugins
> +  This branch adds plugin functionality to GCC.  See the  +  href="http://gcc.gnu.org/wiki/plugins";>plugins wiki for
> +  details.
> +
>  
> 
>  Architecture-specific

Re: make install fails to create gcc ?

[Ben Elliston]

> In any case . .the gcc binary is missing in action .. did make install
> fail in some weird way ?

Possibly, but make should have failed also.

Ben

Re: make install fails to create gcc ?

[Dennis Clarke]

>> In any case . .the gcc binary is missing in action .. did make install
>> fail in some weird way ?
>
> Possibly, but make should have failed also.
>

I re-ran the whole bootstrap process and this time was rewarded with
everything I wanted. I don't know what the issue was earlier. Oh well.

Dennis