Re: SSA_NAMES: should there be an unused, un-free limbo?

[Zdenek Dvorak]

Hello,

> > > I think this might be a good idea.  I think that this requires
> > > a lot of changes (basically going through all uses of bsi_remove
> > > and remove_phi_node and checking them), but it would be cleaner
> > > than the current situation.
> > Agreed.  Tedious work, but it shouldn't be terribly difficult (famous
> > last words).
> 
> I will give it a try (i.e., if it can be done in one afternoon, I will
> send a patch tomorrow :-).

here is a patch.  It passes bootstrap & regtesting except for one
testcase (g++.dg/opt/reg-stack2.C); I do not have time to work further
on it now.

As expected, more complications than I believed appeared.  The changes
to bsi_remove and release_defs would be basically sufficient for ssa
names for real operands, however we are losing ssa names for virtual
operands everywhere, and on several places relying on that they are not
released.

One problem with the patch seems to be that it appears to increase
compile times significantly (by some 4% on compiling preprocessed gcc
sources), I did not investigate where does this slowdown come from.

Zdenek

Index: tree-ssa-loop-im.c
===
*** tree-ssa-loop-im.c  (revision 120177)
--- tree-ssa-loop-im.c  (working copy)
*** free_mem_ref_locs (struct mem_ref_loc *m
*** 897,912 
  static void
  rewrite_mem_refs (tree tmp_var, struct mem_ref_loc *mem_refs)
  {
-   tree var;
-   ssa_op_iter iter;
- 
for (; mem_refs; mem_refs = mem_refs->next)
  {
!   FOR_EACH_SSA_TREE_OPERAND (var, mem_refs->stmt, iter, 
SSA_OP_ALL_VIRTUALS)
!   mark_sym_for_renaming (SSA_NAME_VAR (var));
! 
*mem_refs->ref = tmp_var;
!   update_stmt (mem_refs->stmt);
  }
  }
  
--- 897,907 
  static void
  rewrite_mem_refs (tree tmp_var, struct mem_ref_loc *mem_refs)
  {
for (; mem_refs; mem_refs = mem_refs->next)
  {
!   push_stmt_changes (&mem_refs->stmt);
*mem_refs->ref = tmp_var;
!   pop_stmt_changes (&mem_refs->stmt);
  }
  }
  
Index: tree-complex.c
===
*** tree-complex.c  (revision 120177)
--- tree-complex.c  (working copy)
*** expand_complex_move (block_stmt_iterator
*** 776,781 
--- 776,783 
x = build2_gimple (GIMPLE_MODIFY_STMT, x, r);
bsi_insert_before (bsi, x, BSI_SAME_STMT);
  
+   push_stmt_changes (&stmt);
+ 
if (stmt == bsi_stmt (*bsi))
{
  x = build1 (IMAGPART_EXPR, inner_type, unshare_expr (lhs));
*** expand_complex_move (block_stmt_iterator
*** 794,800 
}
  
update_all_vops (stmt);
!   update_stmt (stmt);
  }
  }
  
--- 796,802 
}
  
update_all_vops (stmt);
!   pop_stmt_changes (&stmt);
  }
  }
  
Index: tree-ssa-loop-manip.c
===
*** tree-ssa-loop-manip.c   (revision 120177)
--- tree-ssa-loop-manip.c   (working copy)
*** verify_loop_closed_ssa (void)
*** 423,429 
if (current_loops == NULL)
  return;
  
!   verify_ssa (false);
  
FOR_EACH_BB (bb)
  {
--- 423,429 
if (current_loops == NULL)
  return;
  
!   verify_ssa (false, false);
  
FOR_EACH_BB (bb)
  {
Index: tree-tailcall.c
===
*** tree-tailcall.c (revision 120177)
--- tree-tailcall.c (working copy)
*** eliminate_tail_call (struct tailcall *t)
*** 752,758 
break;
  
bsi_remove (&bsi, true);
-   release_defs (t);
  }
  
/* Number of executions of function has reduced by the tailcall.  */
--- 752,757 
*** eliminate_tail_call (struct tailcall *t)
*** 798,804 
  }
  
bsi_remove (&t->call_bsi, true);
-   release_defs (call);
  }
  
  /* Add phi nodes for the virtual operands defined in the function to the
--- 797,802 
Index: tree-ssa-dse.c
===
*** tree-ssa-dse.c  (revision 120177)
--- tree-ssa-dse.c  (working copy)
*** dse_optimize_stmt (struct dom_walk_data 
*** 608,617 
  
  /* Remove the dead store.  */
  bsi_remove (&bsi, true);
- 
- /* And release any SSA_NAMEs set in this statement back to the
-SSA_NAME manager.  */
- release_defs (stmt);
}
  
record_voperand_set (dse_gd->stores, &bd->stores, ann->uid);
--- 608,613 
Index: tree-ssa-alias.c
===
*** tree-ssa-alias.c(revision 120177)
--- tree-ssa-alias.c(working copy)
*** compute_may_aliases (void)
*** 943,953 
{
  block_stmt_iterator bsi;
  basic_block bb;
  FOR_EACH_BB (bb)
{
  for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi))
{
! upda

Re: GCC optimizes integer overflow: bug or feature?

[Vincent Lefevre]

On 2006-12-20 23:40:45 +0100, Marcin Dalecki wrote:
> However it's a quite common mistake to forget how  
> "bad" floats "model" real numbers.

It depends on what you are doing. For instance, thanks to the IEEE-754
standard, it is possible to perform exact computations with floats. By
doing unsafe optimizations on floats, gcc may break things. I need to
use -ffloat-store on some of my programs (which are not even based on
the IEEE-754 standard), otherwise they don't work at all.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: GCC optimizes integer overflow: bug or feature?

[Vincent Lefevre]

On 2006-12-21 17:42:15 -0500, Robert Dewar wrote:
> Marcin Dalecki wrote:
> 
> >Of course I didn't think about a substitute for ==. Not! However I think
> >that checks for |x-y| < epsilion, could be really given a significant  
> >speed edge
> >if done in a single go in hardware.
> 
> One thing to ponder here is that "thinks" like this are what lead
> to CISC instruction messes. It just seems obvious to people that
> it will help efficiency to have highly specialized instructions,
> but in practice they gum up the architecture with junk, and a
> careful analysis shows that the actual gain is small at best.
> How many applications spend a significant amount of time doing
> such an epsilon test -- best guess: none.

Indeed, no-one has requested for one in the revision of IEEE 754,
AFAIK.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: GCC optimizes integer overflow: bug or feature?

[Vincent Lefevre]

On 2006-12-19 10:44:25 -0800, Paul Eggert wrote:
> Sure, but that is trickier.  In many cases code operates on
> types like time_t that are signed on some platforms and
> unsigned on others.  It's easy for such code to test for
> overflow if you assume wraparound arithmetic, as code like
> { sum = a + b; if ((sum < a) != (b < 0)) overflow (); } is
> valid regardless of signedness.  It's not so easy if you
> cannot assume wraparound arithmetic, particularly if
> performance is an issue (not the case in GNU expr, but it is
> true elsewhere).

If a has the value -2, b has the value 1 and the user expects to
get -1 regardless of signedness of b, then this is not valid.

So, does anyone assume that the compiler should behave as if a + b
in C were a + b on the integer ring just because many programmers
think so, even though this would be non conforming?

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)