public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <aoliva@redhat.com>
To: gcc-patches@gcc.gnu.org
Subject: [trunk<-vta] Re: [vtab] Permit coalescing of user variables
Date: Mon, 01 Jun 2009 07:39:00 -0000	[thread overview]
Message-ID: <orskikz9mh.fsf_-_@free.oliva.athome.lsd.ic.unicamp.br> (raw)
In-Reply-To: <orabqsm0tz.fsf@free.oliva.athome.lsd.ic.unicamp.br> (Alexandre Oliva's message of "Tue\, 09 Oct 2007 18\:31\:52 -0300")

[-- Attachment #1: Type: text/plain, Size: 1906 bytes --]

This is the first of a series of pings for patches that have long been
in the VTA branch, and most of which had been also submitted for the
trunk, but not reviewed.  They are not specific to VTA or significantly
related with it; rather, they fix bugs or introduce new features that
have been useful to test VTA and assess its performance.

I intend to start submitting VTA proper later this week.  More on that
in a separate upcoming post to gcc@.


A long time ago, when variable tracking at assignments was just a
distant dream, we ran into one of the first contentious points, which
had to do with coalescing SSA names on copyrename.

On the one hand, coalescing unrelated SSA names made for better code (at
least in theory) but poorer debug information; on the other hand,
refraining from coalescing them exploded compile-time memory use.

We currently implement a trade-off by which variables inlined from other
functions can be coalesced, so as to save compile-time memory, reduce
abstraction penalties and retain debug information for out-of-line
functions.

The patch below (ping) implements two other possibilities: refraining
from coalescing even inlined SSA names, which might enable better debug
information to be generated, and enabling coalescing of all related
variables, for better code at the expense of debug information.  The
default remains unchanged.

VTA doesn't really care which of the 3 possibilities is used, it works
equally well with all of them.

On Oct  9, 2007, Alexandre Oliva <aoliva@redhat.com> wrote:

> On Oct  2, 2007, Alexandre Oliva <aoliva@redhat.com> wrote:
>> I guess I could be convinced to introduce yet another command-line
>> option to control this behavior.  How about a tri-state, to permit
>> coalescing of all variables, of non-inline variables and of none
>> variables?

Bootstrapped and regtested on x86_64-linux-gnu and i686-linux-gnu.
Ok for trunk?  


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gcc-ssa-coalesce-vars.patch --]
[-- Type: text/x-patch, Size: 3625 bytes --]

for  gcc/ChangeLog.vta
from  Alexandre Oliva  <aoliva@redhat.com>

	* common.opt (ftree-coalesce-inlined-vars): New.
	(ftree-coalesce-vars): New.
	* doc/invoke.texi: Document them.
	* tree-ssa-copyrename.c (copy_rename_partition_coalesce):
	Implement them.

Index: gcc/common.opt
===================================================================
--- gcc/common.opt.orig	2009-05-28 05:33:39.000000000 -0300
+++ gcc/common.opt	2009-05-28 20:59:37.000000000 -0300
@@ -1170,6 +1170,14 @@ ftree-ch
 Common Report Var(flag_tree_ch) Optimization
 Enable loop header copying on trees
 
+ftree-coalesce-inlined-vars
+Common Report Var(flag_ssa_coalesce_vars,1) Init(1) RejectNegative Optimization
+Permit SSA coalescing of inlined variables only
+
+ftree-coalesce-vars
+Common Report Var(flag_ssa_coalesce_vars,2) Optimization
+Permit SSA coalescing of all variables
+
 ftree-copyrename
 Common Report Var(flag_tree_copyrename) Optimization
 Replace SSA temporaries with better names in copies
Index: gcc/tree-ssa-copyrename.c
===================================================================
--- gcc/tree-ssa-copyrename.c.orig	2009-05-28 05:33:39.000000000 -0300
+++ gcc/tree-ssa-copyrename.c	2009-05-28 21:00:58.000000000 -0300
@@ -189,13 +189,13 @@ copy_rename_partition_coalesce (var_map 
 
   /* Never attempt to coalesce 2 user variables unless one is an inline 
      variable.  */
-  if (!ign1 && !ign2)
+  if (!ign1 && !ign2 && flag_ssa_coalesce_vars)
     {
       if (DECL_FROM_INLINE (root2))
         ign2 = true;
       else if (DECL_FROM_INLINE (root1))
 	ign1 = true;
-      else 
+      else if (flag_ssa_coalesce_vars != 1)
 	{
 	  if (debug)
 	    fprintf (debug, " : 2 different USER vars. No coalesce.\n");
Index: gcc/doc/invoke.texi
===================================================================
--- gcc/doc/invoke.texi.orig	2009-05-28 05:33:39.000000000 -0300
+++ gcc/doc/invoke.texi	2009-05-28 20:58:46.000000000 -0300
@@ -368,8 +368,9 @@ Objective-C and Objective-C++ Dialects}.
 -fsignaling-nans -fsingle-precision-constant -fsplit-ivs-in-unroller @gol
 -fsplit-wide-types -fstack-protector -fstack-protector-all @gol
 -fstrict-aliasing -fstrict-overflow -fthread-jumps -ftracer @gol
--ftree-builtin-call-dce -ftree-ccp -ftree-ch -ftree-copy-prop @gol
--ftree-copyrename -ftree-dce @gol
+-ftree-builtin-call-dce -ftree-ccp -ftree-ch @gol
+-ftree-coalesce-inline-vars -ftree-coalesce-vars @gol
+-ftree-copy-prop -ftree-copyrename -ftree-dce @gol
 -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre -ftree-loop-im @gol
 -ftree-phiprop -ftree-loop-distribution @gol
 -ftree-loop-ivcanon -ftree-loop-linear -ftree-loop-optimize @gol
@@ -6467,6 +6468,19 @@ temporaries to other variables at copy l
 variable names which more closely resemble the original variables.  This flag
 is enabled by default at @option{-O} and higher.
 
+@item -ftree-coalesce-inlined-vars
+Permit the copyrename pass to subject inlined variables to coalescing
+into other variables.  This may harm debug information of such inlined
+variables, but it will keep variables of the main function apart from
+each other, such that they are more likely to contain the expected
+values in a debugging session.  This option is enabled by default.
+
+@item -ftree-coalesce-vars
+Permit the copyrename pass to subject all variables to SSA coalescing.
+This may severely limit the ability to debug a program.  In the negated
+form, this flag prevents SSA coalescing of user variables, including
+inlined ones.
+
 @item -ftree-ter
 @opindex ftree-ter
 Perform temporary expression replacement during the SSA->normal phase.  Single

[-- Attachment #3: Type: text/plain, Size: 257 bytes --]


-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer

  reply	other threads:[~2009-06-01  7:39 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-01 19:05 Alexandre Oliva
2007-10-02  9:15 ` Richard Guenther
2007-10-02 21:02 ` Andrew MacLeod
2007-10-03  1:11   ` Alexandre Oliva
2007-10-09 21:32     ` Alexandre Oliva
2009-06-01  7:39       ` Alexandre Oliva [this message]
2009-06-01  7:44         ` [trunk<-vta] " Alexandre Oliva
2009-06-01 16:11         ` Ian Lance Taylor
2009-06-01 17:35           ` Andrew MacLeod
2009-06-01 19:23             ` Alexandre Oliva
2009-06-02  9:54               ` Richard Guenther
2009-06-02 21:42                 ` Alexandre Oliva
2009-06-03  1:13                   ` Andrew MacLeod
2009-06-03 10:18                     ` Richard Guenther
2009-06-03 17:43                       ` Alexandre Oliva
2009-06-03 18:06                         ` Daniel Jacobowitz
2009-06-03 19:17                           ` Alexandre Oliva
2009-06-03 19:45                             ` Daniel Jacobowitz
2009-06-03 21:42                               ` Alexandre Oliva
2009-06-03 18:18                         ` Richard Guenther
2009-06-03 19:15                           ` Alexandre Oliva
2009-06-03 19:50                             ` Richard Guenther
2009-06-03 19:53                               ` Ian Lance Taylor
2009-10-13 21:27         ` Alexandre Oliva
2011-06-04 12:45           ` Alexandre Oliva
2011-06-04 13:02             ` Jakub Jelinek
2011-06-05 21:07               ` Alexandre Oliva
2011-06-06  2:42                 ` Alexandre Oliva
2012-04-09  5:56             ` Alexandre Oliva
2012-06-13  8:34               ` Alexandre Oliva
2012-06-13  9:48                 ` Richard Guenther

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=orskikz9mh.fsf_-_@free.oliva.athome.lsd.ic.unicamp.br \
    --to=aoliva@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).