[vtab] Permit coalescing of user variables

[vtab] Permit coalescing of user variables

[Alexandre Oliva]

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

This patch should largely reduce memory consumption for some large
machine-generated tests similar to those that triggered the reversion
of the patch that stopped inlined user variables from being coalesced.

Without the upcoming -fvar-tracking-assignments, this patch messes
with debug information of such testcases beyond repair.  We might want
to make this conditional on -fvar-tracking-assignments, maybe.
Thoughts?


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

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

	* tree-ssa-copyrename.c (copy_rename_partition_coalesce):
	Permit coalescing of user variables.

Index: gcc/tree-ssa-copyrename.c
===================================================================
--- gcc/tree-ssa-copyrename.c.orig	2007-08-02 06:03:44.000000000 -0300
+++ gcc/tree-ssa-copyrename.c	2007-08-02 16:09:29.000000000 -0300
@@ -190,22 +190,6 @@ copy_rename_partition_coalesce (var_map 
   ign1 = TREE_CODE (root1) == VAR_DECL && DECL_IGNORED_P (root1);
   ign2 = TREE_CODE (root2) == VAR_DECL && DECL_IGNORED_P (root2);
 
-  /* Never attempt to coalesce 2 user variables unless one is an inline 
-     variable.  */
-  if (!ign1 && !ign2)
-    {
-      if (DECL_FROM_INLINE (root2))
-        ign2 = true;
-      else if (DECL_FROM_INLINE (root1))
-	ign1 = true;
-      else 
-	{
-	  if (debug)
-	    fprintf (debug, " : 2 different USER vars. No coalesce.\n");
-	  return false;
-	}
-    }
-
   /* Don't coalesce if there are two different memory tags.  */
   if (ann1->symbol_mem_tag
       && ann2->symbol_mem_tag

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


-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: [vtab] Permit coalescing of user variables

[Richard Guenther]

On 10/1/07, Alexandre Oliva <aoliva@redhat.com> wrote:
> This patch should largely reduce memory consumption for some large
> machine-generated tests similar to those that triggered the reversion
> of the patch that stopped inlined user variables from being coalesced.
>
> Without the upcoming -fvar-tracking-assignments, this patch messes
> with debug information of such testcases beyond repair.  We might want
> to make this conditional on -fvar-tracking-assignments, maybe.
> Thoughts?

I agree in principle.  Though one could argue that, like with -g,
-fvar-tracking-assignments
should not change generated code.

Richard.

Re: [vtab] Permit coalescing of user variables

[Andrew MacLeod]

Alexandre Oliva wrote:
> This patch should largely reduce memory consumption for some large
> machine-generated tests similar to those that triggered the reversion
> of the patch that stopped inlined user variables from being coalesced.
>
> Without the upcoming -fvar-tracking-assignments, this patch messes
> with debug information of such testcases beyond repair.  We might want
> to make this conditional on -fvar-tracking-assignments, maybe.
> Thoughts?
>
>
>   
Once we don't lose the debug info for the coalesced user vars, this 
would be fine.  I assume this patch would be part of the 
var_tracking_assignments changes.  It is not acceptable in mainline 
until the debug info for these user variables are maintained somehow. 

So do I  understand this correctly?  the improved debug info is being 
controlled by a flag (-fvar-tracking-assignments) rather than just the 
-g option?  If thats the case this patch would clearly have to be under 
the same flag or we'd be destroying debug info we do have today when it 
wasn't used.  I presume the reason is -fvar-tracking-assignments affects 
generated code, and the long term goal is to solve that issue and to 
remove the -fvar-tracking-assignments option and simply use -g?

 Andrew

Re: [vtab] Permit coalescing of user variables

[Alexandre Oliva]

On Oct  2, 2007, Andrew MacLeod <amacleod@redhat.com> wrote:

> I assume this patch would be part of the
> var_tracking_assignments changes.

Yep, that's what the [vtab] is about.

> So do I  understand this correctly?  the improved debug info is being
> controlled by a flag (-fvar-tracking-assignments) rather than just the
> -g option?

Yep, although -fvar-tracking-assignments is enabled by default in the
branch, if optimizing and emitting debug information that supports var
tracking.

> If thats the case this patch would clearly have to be under the same
> flag or we'd be destroying debug info we do have today when it
> wasn't used.

We already destroy debug info today.  And useful debug info while at
that.  We've had this conversation before.  The distiction between
inline and non-inline variables is completely arbitrary, and the
memory explosion out of removing the distiction in the other direction
can be easily obtained by massaging the testcase that was used to
justify the reversion.

Anyhow, given Richard Gunther's objection to
-fvar-tracking-assignments changing the generated code, that I very
much agree with (I still can't believe the thought crossed my mind for
long enough to make to an e-mail I actually sent ;-), 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?

> I presume the reason is
> -fvar-tracking-assignments affects generated code,

ATM, it does, but that's just because it isn't ready yet.  In
shouldn't change generated code in any way, for it's supposed to be
the default for -g at some point in the hopefully not-too-distant
future.

> and the long term goal is to solve that issue and to remove the
> -fvar-tracking-assignments option and simply use -g?

When we're comfortable enough with the debug info it generates and its
not-affecting the generated code, yes.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: [vtab] Permit coalescing of user variables

[Alexandre Oliva]

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

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?

How about this?


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

for  gcc/ChangeLog
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	2007-10-09 18:02:02.000000000 -0300
+++ gcc/common.opt	2007-10-09 18:27:59.000000000 -0300
@@ -1040,6 +1040,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,-1) 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	2007-10-09 18:03:34.000000000 -0300
+++ gcc/tree-ssa-copyrename.c	2007-10-09 18:07:30.000000000 -0300
@@ -192,13 +192,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 > 0)
 	{
 	  if (debug)
 	    fprintf (debug, " : 2 different USER vars. No coalesce.\n");
Index: gcc/doc/invoke.texi
===================================================================
--- gcc/doc/invoke.texi.orig	2007-10-09 03:30:09.000000000 -0300
+++ gcc/doc/invoke.texi	2007-10-09 18:25:14.000000000 -0300
@@ -359,7 +359,8 @@ Objective-C and Objective-C++ Dialects}.
 -ftree-pre  -ftree-ccp  -ftree-dce -ftree-loop-optimize @gol
 -ftree-loop-linear -ftree-loop-im -ftree-loop-ivcanon -fivopts @gol
 -fcheck-data-deps -ftree-parallelize-loops @gol
--ftree-dominator-opts -ftree-dse -ftree-copyrename -ftree-sink @gol
+-ftree-dominator-opts -ftree-dse -ftree-sink @gol
+-ftree-copyrename -ftree-coalesce-inline-vars -ftree-coalesce-vars @gol
 -ftree-ch -ftree-sra -ftree-ter -ftree-fre -ftree-vectorize @gol
 -ftree-vect-loop-version -fvect-cost-model -ftree-salias -fipa-pta -fweb @gol
 -ftree-copy-prop -ftree-store-ccp -ftree-store-copy-prop -fwhole-program @gol
@@ -5804,6 +5805,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.
+
+@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
 Perform temporary expression replacement during the SSA->normal phase.  Single
 use/single def temporaries are replaced at their use location with their

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


-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

[trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Alexandre Oliva]

[-- 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

Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Alexandre Oliva]

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

On Jun  1, 2009, Alexandre Oliva <aoliva@redhat.com> wrote:

> 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.

And the patch below changes the default so that we can optimize more.
This will worsen debug information unless VTA is enabled by default, so
I request a review and approval for inclusion only after VTA or
something equivalent makes it to the trunk.

Ok to install then?

This was bootstrapped and regtested on x86_64-linux-gnu and
i686-pc-linux-gnu, along with the other patches I'm pinging in this
batch.


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

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

	* common.opt (ftree-coalesce-inlined-vars): Change default.
	* doc/invoke.texi: Document default change.  Mention
	var-tracking-assignments.

Index: gcc/common.opt
===================================================================
--- gcc/common.opt.orig	2009-05-28 20:59:37.000000000 -0300
+++ gcc/common.opt	2009-05-28 21:01:15.000000000 -0300
@@ -1171,7 +1171,7 @@ Common Report Var(flag_tree_ch) Optimiza
 Enable loop header copying on trees
 
 ftree-coalesce-inlined-vars
-Common Report Var(flag_ssa_coalesce_vars,1) Init(1) RejectNegative Optimization
+Common Report Var(flag_ssa_coalesce_vars,1) Init(2) RejectNegative Optimization
 Permit SSA coalescing of inlined variables only
 
 ftree-coalesce-vars
Index: gcc/doc/invoke.texi
===================================================================
--- gcc/doc/invoke.texi.orig	2009-05-28 20:58:46.000000000 -0300
+++ gcc/doc/invoke.texi	2009-05-28 21:01:05.000000000 -0300
@@ -6473,11 +6473,12 @@ Permit the copyrename pass to subject in
 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.
+values in a debugging session.
 
 @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
+This may severely limit the ability to debug an optimized program
+compiled without @option{-fvar-tracking-assignments}.  In the negated
 form, this flag prevents SSA coalescing of user variables, including
 inlined ones.
 

[-- Attachment #3: Type: text/plain, Size: 258 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

Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Ian Lance Taylor]

Alexandre Oliva <aoliva@redhat.com> writes:

> +@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.

If we are going to have these options, the documentation needs to be
better.  You have written it from the compiler implementor's point of
view.  You need to rewrite the docs from the user's point of view: what
are the user visible effects of these options?

Also the option names are from the implementor's point of view rather
than the user's point of view.  No ordinary user will ever use an option
named -ftree-coaelesce-inlined-vars, which raises the question of
whether we need the option at all.

Ian

Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Andrew MacLeod]

Ian Lance Taylor wrote:
> Alexandre Oliva <aoliva@redhat.com> writes:
>
>   
>> +@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.
>>     
>
> If we are going to have these options, the documentation needs to be
> better.  You have written it from the compiler implementor's point of
> view.  You need to rewrite the docs from the user's point of view: what
> are the user visible effects of these options?
>
> Also the option names are from the implementor's point of view rather
> than the user's point of view.  No ordinary user will ever use an option
> named -ftree-coaelesce-inlined-vars, which raises the question of
> whether we need the option at all.
>   
I don't think we need the options.  Is there a reason we can't leave the 
current default behaviour the way it is, and have the VTA code simple 
enable the "best" choices for it. (which I think means coalesce 
everything...)

Andrew

Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Alexandre Oliva]

On Jun  1, 2009, Andrew MacLeod <amacleod@redhat.com> wrote:

> Is there a reason we can't leave the current default behaviour the way
> it is, and have the VTA code simple enable the "best" choices for it.

We don't want options used to control generation of debug information
(say the option that enables or disables VTA) to change the generated
code (say enable or disable coalescing), do we?  This would be as bad as
-g/-g0 generating different code.

Personally, I don't see the point of the options either, but I don't see
the point of the current trade-off either.  Corrupting debug info only
for inlined variables is not really better than corrupting debug info
uniformly.

I'd much rather we optimized as well as we could when asked to optimize
(would save compile-time memory and time too), and take care of
preserving debug information through adequade debug information
infrastructure.

But this would imply changing defaults, and would make it difficult to
compare the performance effects of the additional coalescing.

Or, leaving the default as they are, trivial testcases (little to no
inlining) might give an impression that current debug info doesn't suck
as much as it does, reducing the pressure for better infrastructure.

-- 
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

Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Richard Guenther]

On Mon, Jun 1, 2009 at 9:23 PM, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Jun  1, 2009, Andrew MacLeod <amacleod@redhat.com> wrote:
>
>> Is there a reason we can't leave the current default behaviour the way
>> it is, and have the VTA code simple enable the "best" choices for it.
>
> We don't want options used to control generation of debug information
> (say the option that enables or disables VTA) to change the generated
> code (say enable or disable coalescing), do we?  This would be as bad as
> -g/-g0 generating different code.
>
> Personally, I don't see the point of the options either, but I don't see

Me neither, and I am opposed to adding it.

> the point of the current trade-off either.  Corrupting debug info only
> for inlined variables is not really better than corrupting debug info
> uniformly.

Sure, but that is how it works with trade-offs when you lack
a real solution.

Richard.

Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Alexandre Oliva]

On Jun  2, 2009, Richard Guenther <richard.guenther@gmail.com> wrote:

> On Mon, Jun 1, 2009 at 9:23 PM, Alexandre Oliva <aoliva@redhat.com> wrote:
>> On Jun  1, 2009, Andrew MacLeod <amacleod@redhat.com> wrote:
>> 
>>> Is there a reason we can't leave the current default behaviour the way
>>> it is, and have the VTA code simple enable the "best" choices for it.
>> 
>> We don't want options used to control generation of debug information
>> (say the option that enables or disables VTA) to change the generated
>> code (say enable or disable coalescing), do we?  This would be as bad as
>> -g/-g0 generating different code.
>> 
>> Personally, I don't see the point of the options either, but I don't see

> Me neither, and I am opposed to adding it.

I'm missing your rationale here as well.  It would help if you at least
voiced what you suggest we do instead.


Do you propose we keep on sacrificing run-time performance in favor of
debug info that users might not even be interested in (say, compile with
-O3 -g0), rather than trivially permitting the user to easily tune for
one or the other?


We don't even have evidence that the current trade-off is useful for
users.  It sacrifices performance to make for better debug info, but
then it screws debug info all over (we inline a lot) to save
compile-time performance.

We might as well not sacrifice any performance whatsoever, compile- or
run-time.  That would at least make sense when explained to a user.  The
“oh, but if it's inlined, we don't care” rule that's implemented might
have made sense when GDB couldn't display info from inlined variables.
Now it does, so we can no longer hide behind its shortcoming.

-- 
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

Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Andrew MacLeod]

Alexandre Oliva wrote:
> On Jun  2, 2009, Richard Guenther <richard.guenther@gmail.com> wrote:
>
>   
>> On Mon, Jun 1, 2009 at 9:23 PM, Alexandre Oliva <aoliva@redhat.com> wrote:
>>     
>>> On Jun  1, 2009, Andrew MacLeod <amacleod@redhat.com> wrote:
>>>
>>>       
>>>> Is there a reason we can't leave the current default behaviour the way
>>>> it is, and have the VTA code simple enable the "best" choices for it.
>>>>         
>>> We don't want options used to control generation of debug information
>>> (say the option that enables or disables VTA) to change the generated
>>> code (say enable or disable coalescing), do we?  This would be as bad as
>>> -g/-g0 generating different code.
>>>
>>> Personally, I don't see the point of the options either, but I don't see
>>>       
>
>   
>> Me neither, and I am opposed to adding it.
>>     
>
> I'm missing your rationale here as well.  It would help if you at least
> voiced what you suggest we do instead.
>
>   
I think we are simply proposing that when VTA code is added and enabled, 
the default behaviour is then changed such that we do this coalescing.  
Until then it stays with the current tradeoffs. no options required...

At least that's all I meant.

Andrew

Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Richard Guenther]

On Wed, Jun 3, 2009 at 3:13 AM, Andrew MacLeod <amacleod@redhat.com> wrote:
> Alexandre Oliva wrote:
>>
>> On Jun  2, 2009, Richard Guenther <richard.guenther@gmail.com> wrote:
>>
>>
>>>
>>> On Mon, Jun 1, 2009 at 9:23 PM, Alexandre Oliva <aoliva@redhat.com>
>>> wrote:
>>>
>>>>
>>>> On Jun  1, 2009, Andrew MacLeod <amacleod@redhat.com> wrote:
>>>>
>>>>
>>>>>
>>>>> Is there a reason we can't leave the current default behaviour the way
>>>>> it is, and have the VTA code simple enable the "best" choices for it.
>>>>>
>>>>
>>>> We don't want options used to control generation of debug information
>>>> (say the option that enables or disables VTA) to change the generated
>>>> code (say enable or disable coalescing), do we?  This would be as bad as
>>>> -g/-g0 generating different code.
>>>>
>>>> Personally, I don't see the point of the options either, but I don't see
>>>>
>>
>>
>>>
>>> Me neither, and I am opposed to adding it.
>>>
>>
>> I'm missing your rationale here as well.  It would help if you at least
>> voiced what you suggest we do instead.
>>
>>
>
> I think we are simply proposing that when VTA code is added and enabled, the
> default behaviour is then changed such that we do this coalescing.  Until
> then it stays with the current tradeoffs. no options required...
>
> At least that's all I meant.

Right, this is what I would suggest as well.

Richard.

> Andrew
>
>

Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Alexandre Oliva]

On Jun  3, 2009, Richard Guenther <richard.guenther@gmail.com> wrote:

> On Wed, Jun 3, 2009 at 3:13 AM, Andrew MacLeod <amacleod@redhat.com> wrote:
>> I think we are simply proposing that when VTA code is added and enabled, the
>> default behaviour is then changed such that we do this coalescing.  Until
>> then it stays with the current tradeoffs. no options required...

> Right, this is what I would suggest as well.

Hmm...  That's a “wilder” path than the incremental one I had in mind.

I wasn't thinking VTA would have been enabled by default right away.
Even if it was, I think it would be important to retain a possibility to
turn it off, at least until it's proven on more ports than the testing
it got so far.

And then, if VTA can be turned on or off, other trade-offs (like this
one), that work better with VTA but worse without it, should be
controllable too.

And then, there's the factor of being able to measure the impact of the
changes.  If we support the options, we can simply compare one with the
other, using the very same compiler.  If we don't, at the very least
we'd have to maintain patches that revert to past behavior, or that
advance to future behavior, build more toolchains and compare compiler
output like that.

This was my reasoning to implement the proposed options.  They're useful
on their own right now, regardless of VTA.  One of them can bring about
significant compile-time and run-time improvements, whereas the other
can bring about slightly better debug information.  With or without VTA.

Sure enough, if VTA goes in and becomes default and can't be disabled,
the options cease to make much sense.  We can remove them then, when and
if it happens.  But since so far there's no indication that VTA is
actually going in, rejecting this patch on the grounds of an unwarranted
assumption comes off as very odd to me.

-- 
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

Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Daniel Jacobowitz]

On Wed, Jun 03, 2009 at 02:43:27PM -0300, Alexandre Oliva wrote:
> Sure enough, if VTA goes in and becomes default and can't be disabled,
> the options cease to make much sense.  We can remove them then, when and
> if it happens.  But since so far there's no indication that VTA is
> actually going in, rejecting this patch on the grounds of an unwarranted
> assumption comes off as very odd to me.

So, just make the switch flipped by whatever bit of GCC decides VTA is
enabled?

-- 
Daniel Jacobowitz
CodeSourcery

Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Alexandre Oliva]

On Jun  3, 2009, Daniel Jacobowitz <drow@false.org> wrote:

> On Wed, Jun 03, 2009 at 02:43:27PM -0300, Alexandre Oliva wrote:
>> Sure enough, if VTA goes in and becomes default and can't be disabled,
>> the options cease to make much sense.  We can remove them then, when and
>> if it happens.  But since so far there's no indication that VTA is
>> actually going in, rejecting this patch on the grounds of an unwarranted
>> assumption comes off as very odd to me.

> So, just make the switch flipped by whatever bit of GCC decides VTA is
> enabled?

And then options that control debug information start controlling
executable code as well, and the entire universe collapses ;-P :-D

More on this upthread.

-- 
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

Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Daniel Jacobowitz]

On Wed, Jun 03, 2009 at 04:16:45PM -0300, Alexandre Oliva wrote:
> On Jun  3, 2009, Daniel Jacobowitz <drow@false.org> wrote:
> 
> > On Wed, Jun 03, 2009 at 02:43:27PM -0300, Alexandre Oliva wrote:
> >> Sure enough, if VTA goes in and becomes default and can't be disabled,
> >> the options cease to make much sense.  We can remove them then, when and
> >> if it happens.  But since so far there's no indication that VTA is
> >> actually going in, rejecting this patch on the grounds of an unwarranted
> >> assumption comes off as very odd to me.
> 
> > So, just make the switch flipped by whatever bit of GCC decides VTA is
> > enabled?
> 
> And then options that control debug information start controlling
> executable code as well, and the entire universe collapses ;-P :-D
> 
> More on this upthread.

I think you've misunderstood my point.

If you want ports to be able to set the default for VTA as it is
tested with them (which I'm not convinced is a good idea, anyway) then
that setting is independent of -g.  That's the right place to control
coalescing.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Alexandre Oliva]

On Jun  3, 2009, Daniel Jacobowitz <drow@false.org> wrote:

> On Wed, Jun 03, 2009 at 04:16:45PM -0300, Alexandre Oliva wrote:
>> On Jun  3, 2009, Daniel Jacobowitz <drow@false.org> wrote:
>> > So, just make the switch flipped by whatever bit of GCC decides VTA is
>> > enabled?

>> And then options that control debug information start controlling
>> executable code as well, and the entire universe collapses ;-P :-D

> I think you've misunderstood my point.

We seem to have misunderstandood each other, indeed :-(

> If you want ports to be able to set the default for VTA as it is
> tested with them

Oh, but I don't.  Not per-port defaults.  What I had in mind was more
like a flag day, with options that would get you post-flag-day behavior
before it, and pre-flag-day behavior after it.

-- 
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

Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Richard Guenther]

On Wed, Jun 3, 2009 at 7:43 PM, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Jun  3, 2009, Richard Guenther <richard.guenther@gmail.com> wrote:
>
>> On Wed, Jun 3, 2009 at 3:13 AM, Andrew MacLeod <amacleod@redhat.com> wrote:
>>> I think we are simply proposing that when VTA code is added and enabled, the
>>> default behaviour is then changed such that we do this coalescing.  Until
>>> then it stays with the current tradeoffs. no options required...
>
>> Right, this is what I would suggest as well.
>
> Hmm...  That's a “wilder” path than the incremental one I had in mind.
>
> I wasn't thinking VTA would have been enabled by default right away.
> Even if it was, I think it would be important to retain a possibility to
> turn it off, at least until it's proven on more ports than the testing
> it got so far.
>
> And then, if VTA can be turned on or off, other trade-offs (like this
> one), that work better with VTA but worse without it, should be
> controllable too.
>
> And then, there's the factor of being able to measure the impact of the
> changes.  If we support the options, we can simply compare one with the
> other, using the very same compiler.  If we don't, at the very least
> we'd have to maintain patches that revert to past behavior, or that
> advance to future behavior, build more toolchains and compare compiler
> output like that.
>
> This was my reasoning to implement the proposed options.  They're useful
> on their own right now, regardless of VTA.  One of them can bring about
> significant compile-time and run-time improvements, whereas the other
> can bring about slightly better debug information.  With or without VTA.
>
> Sure enough, if VTA goes in and becomes default and can't be disabled,
> the options cease to make much sense.  We can remove them then, when and
> if it happens.  But since so far there's no indication that VTA is
> actually going in, rejecting this patch on the grounds of an unwarranted
> assumption comes off as very odd to me.

Btw, _is_ there really a such big effect with enabling the extra coalescing?

Richard.

> --
> 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
>

Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Alexandre Oliva]

On Jun  3, 2009, Richard Guenther <richard.guenther@gmail.com> wrote:

> Btw, _is_ there really a such big effect with enabling the extra coalescing?

I'm pretty sure I even posted SPEC results back when I first proposed
these changes.

I remember there was a huge effect in compile time for some
machine-generated sources.  Surely if enabling coalescing for inlined
variables had such a huge effect, enabling it for non-inlined variables
would have an even larger effect.

Difference in performance was nothing to write home about, but when
you're trying to squeeze the last bit of performance from a program,
losing it to debug info you're not even interested in doesn't speak well
of GCC.

-- 
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

Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Richard Guenther]

On Wed, Jun 3, 2009 at 9:15 PM, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Jun  3, 2009, Richard Guenther <richard.guenther@gmail.com> wrote:
>
>> Btw, _is_ there really a such big effect with enabling the extra coalescing?
>
> I'm pretty sure I even posted SPEC results back when I first proposed
> these changes.
>
> I remember there was a huge effect in compile time for some
> machine-generated sources.  Surely if enabling coalescing for inlined
> variables had such a huge effect, enabling it for non-inlined variables
> would have an even larger effect.
>
> Difference in performance was nothing to write home about, but when
> you're trying to squeeze the last bit of performance from a program,
> losing it to debug info you're not even interested in doesn't speak well
> of GCC.

Ok, I think the tristate option may be useful then.  Can we enable
full coalescing at -O3 then?  I'll defer to Ian to approve the patch.

Thanks,
Richard.

Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Ian Lance Taylor]

Richard Guenther <richard.guenther@gmail.com> writes:

> On Wed, Jun 3, 2009 at 9:15 PM, Alexandre Oliva <aoliva@redhat.com> wrote:
>> On Jun  3, 2009, Richard Guenther <richard.guenther@gmail.com> wrote:
>>
>>> Btw, _is_ there really a such big effect with enabling the extra coalescing?
>>
>> I'm pretty sure I even posted SPEC results back when I first proposed
>> these changes.
>>
>> I remember there was a huge effect in compile time for some
>> machine-generated sources.  Surely if enabling coalescing for inlined
>> variables had such a huge effect, enabling it for non-inlined variables
>> would have an even larger effect.
>>
>> Difference in performance was nothing to write home about, but when
>> you're trying to squeeze the last bit of performance from a program,
>> losing it to debug info you're not even interested in doesn't speak well
>> of GCC.
>
> Ok, I think the tristate option may be useful then.  Can we enable
> full coalescing at -O3 then?  I'll defer to Ian to approve the patch.

I don't even understand the patch.  I don't think I should be the one to
approve it.  I don't mind if somebody else approves it, but if I'm going
to approve it I would want to see documentation with a user of the
compiler can understand.

Ian

Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Alexandre Oliva]

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

On Jun  1, 2009, Alexandre Oliva <aoliva@redhat.com> wrote:

> 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.

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

On Jun  1, 2009, Alexandre Oliva <aoliva@redhat.com> also wrote:

> And the patch below changes the default so that we can optimize more.

This patch combines the two patches described above, now that VTA is
enabled by default.  I couldn't make sense of how the code changes I'd
proposed in earlier versions of the patches implemented what I'd
documented.  I suspect it didn't, so I changed it so that it does.

I haven't finished testing this patch yet.  I suspect it won't go in
unchanged; maybe the default should vary depending on whether debug info
is dwarf-2+ (so that VTA is avaialble and can help), or on optimization
levels, so this is more for discussion than for approval.  However, if
you think it should go in, feel free to ok it ;-) and then I'd check it
in once I'm done testing.

Please don't suggest changing optimization behavior (which is what this
flags controls) based on whether VTA, VT or -g are enabled or disabled.
This has been suggested before, but debug options such as
-fvar-tracking* and -g* should never influence optimizations.

Thanks,


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

for  gcc/ChangeLog
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-10-12 16:42:47.000000000 -0300
+++ gcc/common.opt	2009-10-12 17:13:41.000000000 -0300
@@ -1238,6 +1238,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(2) RejectNegative Optimization
+Enable coalescing of copy-related user variables that are inlined
+
+ftree-coalesce-vars
+Common Report Var(flag_ssa_coalesce_vars,2) Optimization
+Enable coalescing of all copy-related user 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-10-12 16:42:46.000000000 -0300
+++ gcc/tree-ssa-copyrename.c	2009-10-12 17:17:07.000000000 -0300
@@ -187,15 +187,14 @@ copy_rename_partition_coalesce (var_map 
   ign1 = TREE_CODE (root1) == VAR_DECL && DECL_IGNORED_P (root1);
   ign2 = TREE_CODE (root2) == VAR_DECL && DECL_IGNORED_P (root2);
 
-  /* Never attempt to coalesce 2 user variables unless one is an inline 
-     variable.  */
+  /* Refrain from coalescing user variables, if requested.  */
   if (!ign1 && !ign2)
     {
-      if (DECL_FROM_INLINE (root2))
+      if (flag_ssa_coalesce_vars && DECL_FROM_INLINE (root2))
         ign2 = true;
-      else if (DECL_FROM_INLINE (root1))
+      else if (flag_ssa_coalesce_vars && DECL_FROM_INLINE (root1))
 	ign1 = true;
-      else 
+      else if (flag_ssa_coalesce_vars != 2)
 	{
 	  if (debug)
 	    fprintf (debug, " : 2 different USER vars. No coalesce.\n");
Index: gcc/doc/invoke.texi
===================================================================
--- gcc/doc/invoke.texi.orig	2009-10-12 16:42:46.000000000 -0300
+++ gcc/doc/invoke.texi	2009-10-12 17:09:14.000000000 -0300
@@ -379,8 +379,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
@@ -6761,6 +6762,22 @@ 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
+A more limited form of @option{-ftree-coalesce-vars}, that performs
+the transformation if at least one of the variables was inlined.  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 was the default in GCC versions older than 4.5.
+
+@item -ftree-coalesce-vars
+Tell the compiler to attempt to combine small user variables that
+don't need to live in memory, when it finds a copy between them.  This
+may severely limit the ability to debug an optimized program compiled
+without @option{-fvar-tracking-assignments}.  In the negated form,
+this flag prevents SSA coalescing of user variables, including inlined
+ones.  This option is enabled by default.
+
 @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

Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Alexandre Oliva]

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

On Oct 13, 2009, Alexandre Oliva <aoliva@redhat.com> wrote:

> On Jun  1, 2009, Alexandre Oliva <aoliva@redhat.com> wrote:
>> 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.

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

> On Jun  1, 2009, Alexandre Oliva <aoliva@redhat.com> also wrote:

>> And the patch below changes the default so that we can optimize more.

> This patch combines the two patches described above, now that VTA is
> enabled by default.

This is an updated version of the patch, adjusting the testcases that
didn't expect this kind of variable coalescing.  Regstrapped on
x86_64-linux-gnu and i686-linux-gnu, along with a patch for a latent
cprop problem that caused a compare-debug failure in the ada rts.
Ok to install?


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

for  gcc/ChangeLog
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.

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

	* g++.dg/tree-ssa/ivopts-2.C: Adjust for coalescing.
	* gcc.dg/tree-ssa/forwprop-11.c: Likewise.
	* gcc.dg/tree-ssa/ssa-fre-1.c: Likewise.
	* gcc.dg/guality/bswaptest.c: Avoid coalescing and early death
	of test variable.
	* gcc.dg/guality/clztest.c: Likewise.
	* gcc.dg/guality/ctztest.c: Likewise.
	* gcc.dg/guality/rotatetest.c: Likewise.

Index: gcc/common.opt
===================================================================
--- gcc/common.opt.orig	2011-06-04 09:00:30.005102549 -0300
+++ gcc/common.opt	2011-06-04 09:01:29.199347556 -0300
@@ -1898,6 +1898,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(2) RejectNegative Optimization
+Enable coalescing of copy-related user variables that are inlined
+
+ftree-coalesce-vars
+Common Report Var(flag_ssa_coalesce_vars,2) Optimization
+Enable coalescing of all copy-related user 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	2011-06-04 09:00:30.160103200 -0300
+++ gcc/tree-ssa-copyrename.c	2011-06-04 09:01:29.252347770 -0300
@@ -194,20 +194,21 @@ copy_rename_partition_coalesce (var_map 
   ign1 = TREE_CODE (root1) == VAR_DECL && DECL_IGNORED_P (root1);
   ign2 = TREE_CODE (root2) == VAR_DECL && DECL_IGNORED_P (root2);
 
-  /* Never attempt to coalesce 2 user variables unless one is an inline
-     variable.  */
+  /* Refrain from coalescing user variables, if requested.  */
   if (!ign1 && !ign2)
     {
-      if (DECL_FROM_INLINE (root2))
+      if (flag_ssa_coalesce_vars && DECL_FROM_INLINE (root2))
         ign2 = true;
-      else if (DECL_FROM_INLINE (root1))
+      else if (flag_ssa_coalesce_vars && DECL_FROM_INLINE (root1))
 	ign1 = true;
-      else
+      else if (flag_ssa_coalesce_vars != 2)
 	{
 	  if (debug)
 	    fprintf (debug, " : 2 different USER vars. No coalesce.\n");
 	  return false;
 	}
+      else
+	ign2 = true;
     }
 
   /* If both values have default defs, we can't coalesce.  If only one has a
Index: gcc/doc/invoke.texi
===================================================================
--- gcc/doc/invoke.texi.orig	2011-06-04 09:00:30.665105322 -0300
+++ gcc/doc/invoke.texi	2011-06-04 09:01:29.479348698 -0300
@@ -395,8 +395,8 @@ 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-bit-ccp @gol
--ftree-builtin-call-dce -ftree-ccp -ftree-ch -ftree-copy-prop @gol
+-ftree-bit-ccp -ftree-builtin-call-dce -ftree-ccp -ftree-ch @gol
+-ftree-coalesce-inline-vars -ftree-coalesce-vars -ftree-copy-prop @gol
 -ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse @gol
 -ftree-forwprop -ftree-fre -ftree-loop-if-convert @gol
 -ftree-loop-if-convert-stores -ftree-loop-im @gol
@@ -7231,6 +7231,22 @@ 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
+A more limited form of @option{-ftree-coalesce-vars}, that performs
+the transformation if at least one of the variables was inlined.  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 was the default in GCC versions older than 4.7.
+
+@item -ftree-coalesce-vars
+Tell the compiler to attempt to combine small user variables that
+don't need to live in memory, when it finds a copy between them.  This
+may severely limit the ability to debug an optimized program compiled
+without @option{-fvar-tracking-assignments}.  In the negated form,
+this flag prevents SSA coalescing of user variables, including inlined
+ones.  This option is enabled by default.
+
 @item -ftree-ter
 @opindex ftree-ter
 Perform temporary expression replacement during the SSA->normal phase.  Single
Index: gcc/testsuite/g++.dg/tree-ssa/ivopts-2.C
===================================================================
--- gcc/testsuite/g++.dg/tree-ssa/ivopts-2.C.orig	2011-06-04 09:13:29.613784393 -0300
+++ gcc/testsuite/g++.dg/tree-ssa/ivopts-2.C	2011-06-04 09:16:24.688235836 -0300
@@ -7,5 +7,5 @@ void test (int *b, int *e, int stride)
       *p = 1;
   }
 
-/* { dg-final { scan-tree-dump-times "PHI <p" 1 "ivopts"} } */
+/* { dg-final { scan-tree-dump-times "PHI <\[pb\]" 1 "ivopts"} } */
 /* { dg-final { cleanup-tree-dump "ivopts" } } */
Index: gcc/testsuite/gcc.dg/tree-ssa/forwprop-11.c
===================================================================
--- gcc/testsuite/gcc.dg/tree-ssa/forwprop-11.c.orig	2011-06-04 09:08:19.363853778 -0300
+++ gcc/testsuite/gcc.dg/tree-ssa/forwprop-11.c	2011-06-04 09:09:12.127024253 -0300
@@ -16,5 +16,5 @@ int g(int *p, int n)
   return q[-1];
 }
 
-/* { dg-final { scan-tree-dump-times "= MEM\\\[\\\(int \\\*\\\)a_.. \\\+ 4B\\\];" 2 "forwprop1" } } */
+/* { dg-final { scan-tree-dump-times "= MEM\\\[\\\(int \\\*\\\)\[ap\]_.. \\\+ 4B\\\];" 2 "forwprop1" } } */
 /* { dg-final { cleanup-tree-dump "forwprop1" } } */
Index: gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-1.c
===================================================================
--- gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-1.c.orig	2011-06-04 09:11:37.164466849 -0300
+++ gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-1.c	2011-06-04 09:11:41.365479111 -0300
@@ -11,5 +11,5 @@ int f(int *a)
   return *c + t;
 }
 
-/* { dg-final { scan-tree-dump "Replaced \\\*c_\[^\n\].*with t_" "fre1" } } */
+/* { dg-final { scan-tree-dump "Replaced \\\*\[ac\]_\[^\n\].*with t_" "fre1" } } */
 /* { dg-final { cleanup-tree-dump "fre1" } } */
Index: gcc/testsuite/gcc.dg/guality/bswaptest.c
===================================================================
--- gcc/testsuite/gcc.dg/guality/bswaptest.c.orig	2011-06-04 09:35:38.954014890 -0300
+++ gcc/testsuite/gcc.dg/guality/bswaptest.c	2011-06-04 09:35:51.345054255 -0300
@@ -10,7 +10,7 @@ foo (long x)
   long g = f;
   asm volatile ("" : "+r" (f));
   vv++;		/* { dg-final { gdb-test 12 "g" "f" } } */
-  return f;
+  return f - g;
 }
 
 __attribute__((noclone, noinline)) int
@@ -20,7 +20,7 @@ bar (int x)
   int g = f;
   asm volatile ("" : "+r" (f));
   vv++;		/* { dg-final { gdb-test 22 "g" "f" } } */
-  return f;
+  return f - g;
 }
 
 int
Index: gcc/testsuite/gcc.dg/guality/clztest.c
===================================================================
--- gcc/testsuite/gcc.dg/guality/clztest.c.orig	2011-06-04 09:35:39.202015678 -0300
+++ gcc/testsuite/gcc.dg/guality/clztest.c	2011-06-04 09:36:17.710136856 -0300
@@ -10,7 +10,7 @@ foo (long x)
   long g = f;
   asm volatile ("" : "+r" (f));
   vv++;		/* { dg-final { gdb-test 12 "g" "f" } } */
-  return f;
+  return f - g;
 }
 
 __attribute__((noinline, noclone)) long
@@ -20,7 +20,7 @@ bar (long x)
   long g = f;
   asm volatile ("" : "+r" (f));
   vv++;		/* { dg-final { gdb-test 22 "g" "f" } } */
-  return f;
+  return f - g;
 }
 
 int
Index: gcc/testsuite/gcc.dg/guality/ctztest.c
===================================================================
--- gcc/testsuite/gcc.dg/guality/ctztest.c.orig	2011-06-04 09:35:39.463016509 -0300
+++ gcc/testsuite/gcc.dg/guality/ctztest.c	2011-06-04 09:36:33.143184587 -0300
@@ -10,7 +10,7 @@ foo (long x)
   long g = f;
   asm volatile ("" : "+r" (f));
   vv++;		/* { dg-final { gdb-test 12 "g" "f" } } */
-  return f;
+  return f - g;
 }
 
 __attribute__((noinline, noclone)) long
@@ -20,7 +20,7 @@ bar (long x)
   long g = f;
   asm volatile ("" : "+r" (f));
   vv++;		/* { dg-final { gdb-test 22 "g" "f" } } */
-  return f;
+  return f - g;
 }
 
 int
Index: gcc/testsuite/gcc.dg/guality/rotatetest.c
===================================================================
--- gcc/testsuite/gcc.dg/guality/rotatetest.c.orig	2011-06-04 09:32:07.155300180 -0300
+++ gcc/testsuite/gcc.dg/guality/rotatetest.c	2011-06-04 09:34:46.757846376 -0300
@@ -10,7 +10,7 @@ f1 (unsigned long x)
   long g = f;
   asm volatile ("" : "+r" (f));
   vv++;		/* { dg-final { gdb-test 12 "g" "f" } } */
-  return f;
+  return f - g;
 }
 
 __attribute__((noclone, noinline)) long
@@ -20,7 +20,7 @@ f2 (unsigned long x, int y)
   long g = f;
   asm volatile ("" : "+r" (f));
   vv++;		/* { dg-final { gdb-test 22 "g" "f" } } */
-  return f;
+  return f - g;
 }
 
 __attribute__((noclone, noinline)) long
@@ -30,7 +30,7 @@ f3 (unsigned long x, int y)
   long g = f;
   asm volatile ("" : "+r" (f));
   vv++;		/* { dg-final { gdb-test 32 "g" "f" } } */
-  return f;
+  return f - g;
 }
 
 __attribute__((noclone, noinline)) unsigned int
@@ -40,7 +40,7 @@ f4 (unsigned int x)
   unsigned int g = f;
   asm volatile ("" : "+r" (f));
   vv++;		/* { dg-final { gdb-test 42 "g" "f" } } */
-  return f;
+  return f - g;
 }
 
 __attribute__((noclone, noinline)) unsigned int
@@ -50,7 +50,7 @@ f5 (unsigned int x, int y)
   unsigned int g = f;
   asm volatile ("" : "+r" (f));
   vv++;		/* { dg-final { gdb-test 52 "g" "f" } } */
-  return f;
+  return f - g;
 }
 
 __attribute__((noclone, noinline)) unsigned int
@@ -60,7 +60,7 @@ f6 (unsigned int x, int y)
   unsigned int g = f;
   asm volatile ("" : "+r" (f));
   vv++;		/* { dg-final { gdb-test 62 "g" "f" } } */
-  return f;
+  return f - g;
 }
 
 int

[-- Attachment #3: Type: text/plain, Size: 258 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

Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Jakub Jelinek]

On Sat, Jun 04, 2011 at 09:40:38AM -0300, Alexandre Oliva wrote:

The following changes all look wrong to me, they make the tests totally
useless.  If both f and g are used in real code after the asm volatile, then
the both f and g will likely live in some register or memory.
The whole point of the construct in the tests is that f has at that spot
a reg or mem location, but g isn't present anywhere anymore (as the compiler
doesn't or shouldn't know that asm volatile hasn't changed f), thus it
should represent them as bswap/clz/ctz/rotate.

> --- gcc/testsuite/gcc.dg/guality/bswaptest.c.orig	2011-06-04 09:35:38.954014890 -0300
> +++ gcc/testsuite/gcc.dg/guality/bswaptest.c	2011-06-04 09:35:51.345054255 -0300
> @@ -10,7 +10,7 @@ foo (long x)
>    long g = f;
>    asm volatile ("" : "+r" (f));
>    vv++;		/* { dg-final { gdb-test 12 "g" "f" } } */
> -  return f;
> +  return f - g;
>  }
>  
>  __attribute__((noclone, noinline)) int
> @@ -20,7 +20,7 @@ bar (int x)
>    int g = f;
>    asm volatile ("" : "+r" (f));
>    vv++;		/* { dg-final { gdb-test 22 "g" "f" } } */
> -  return f;
> +  return f - g;
>  }
>  
>  int
> Index: gcc/testsuite/gcc.dg/guality/clztest.c
> ===================================================================
> --- gcc/testsuite/gcc.dg/guality/clztest.c.orig	2011-06-04 09:35:39.202015678 -0300
> +++ gcc/testsuite/gcc.dg/guality/clztest.c	2011-06-04 09:36:17.710136856 -0300
> @@ -10,7 +10,7 @@ foo (long x)
>    long g = f;
>    asm volatile ("" : "+r" (f));
>    vv++;		/* { dg-final { gdb-test 12 "g" "f" } } */
> -  return f;
> +  return f - g;
>  }
>  
>  __attribute__((noinline, noclone)) long
> @@ -20,7 +20,7 @@ bar (long x)
>    long g = f;
>    asm volatile ("" : "+r" (f));
>    vv++;		/* { dg-final { gdb-test 22 "g" "f" } } */
> -  return f;
> +  return f - g;
>  }
>  
>  int
> Index: gcc/testsuite/gcc.dg/guality/ctztest.c
> ===================================================================
> --- gcc/testsuite/gcc.dg/guality/ctztest.c.orig	2011-06-04 09:35:39.463016509 -0300
> +++ gcc/testsuite/gcc.dg/guality/ctztest.c	2011-06-04 09:36:33.143184587 -0300
> @@ -10,7 +10,7 @@ foo (long x)
>    long g = f;
>    asm volatile ("" : "+r" (f));
>    vv++;		/* { dg-final { gdb-test 12 "g" "f" } } */
> -  return f;
> +  return f - g;
>  }
>  
>  __attribute__((noinline, noclone)) long
> @@ -20,7 +20,7 @@ bar (long x)
>    long g = f;
>    asm volatile ("" : "+r" (f));
>    vv++;		/* { dg-final { gdb-test 22 "g" "f" } } */
> -  return f;
> +  return f - g;
>  }
>  
>  int
> Index: gcc/testsuite/gcc.dg/guality/rotatetest.c
> ===================================================================
> --- gcc/testsuite/gcc.dg/guality/rotatetest.c.orig	2011-06-04 09:32:07.155300180 -0300
> +++ gcc/testsuite/gcc.dg/guality/rotatetest.c	2011-06-04 09:34:46.757846376 -0300
> @@ -10,7 +10,7 @@ f1 (unsigned long x)
>    long g = f;
>    asm volatile ("" : "+r" (f));
>    vv++;		/* { dg-final { gdb-test 12 "g" "f" } } */
> -  return f;
> +  return f - g;
>  }
>  
>  __attribute__((noclone, noinline)) long
> @@ -20,7 +20,7 @@ f2 (unsigned long x, int y)
>    long g = f;
>    asm volatile ("" : "+r" (f));
>    vv++;		/* { dg-final { gdb-test 22 "g" "f" } } */
> -  return f;
> +  return f - g;
>  }
>  
>  __attribute__((noclone, noinline)) long
> @@ -30,7 +30,7 @@ f3 (unsigned long x, int y)
>    long g = f;
>    asm volatile ("" : "+r" (f));
>    vv++;		/* { dg-final { gdb-test 32 "g" "f" } } */
> -  return f;
> +  return f - g;
>  }
>  
>  __attribute__((noclone, noinline)) unsigned int
> @@ -40,7 +40,7 @@ f4 (unsigned int x)
>    unsigned int g = f;
>    asm volatile ("" : "+r" (f));
>    vv++;		/* { dg-final { gdb-test 42 "g" "f" } } */
> -  return f;
> +  return f - g;
>  }
>  
>  __attribute__((noclone, noinline)) unsigned int
> @@ -50,7 +50,7 @@ f5 (unsigned int x, int y)
>    unsigned int g = f;
>    asm volatile ("" : "+r" (f));
>    vv++;		/* { dg-final { gdb-test 52 "g" "f" } } */
> -  return f;
> +  return f - g;
>  }
>  
>  __attribute__((noclone, noinline)) unsigned int
> @@ -60,7 +60,7 @@ f6 (unsigned int x, int y)
>    unsigned int g = f;
>    asm volatile ("" : "+r" (f));
>    vv++;		/* { dg-final { gdb-test 62 "g" "f" } } */
> -  return f;
> +  return f - g;
>  }
>  
>  int

	Jakub

Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Alexandre Oliva]

On Jun  4, 2011, Jakub Jelinek <jakub@redhat.com> wrote:

> The following changes all look wrong to me, they make the tests totally
> useless.  If both f and g are used in real code after the asm volatile, then
> the both f and g will likely live in some register or memory.
> The whole point of the construct in the tests is that f has at that spot
> a reg or mem location, but g isn't present anywhere anymore (as the compiler
> doesn't or shouldn't know that asm volatile hasn't changed f), thus it
> should represent them as bswap/clz/ctz/rotate.

I see.  I'll try to figure out why that didn't work.  Maybe the input
operands were clobbered or something, or maybe g used to be saved
elsewhere before and now it no longer is.

-- 
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

Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Alexandre Oliva]

On Jun  5, 2011, Alexandre Oliva <aoliva@redhat.com> wrote:

> On Jun  4, 2011, Jakub Jelinek <jakub@redhat.com> wrote:
>> The following changes all look wrong to me, they make the tests totally
>> useless.  If both f and g are used in real code after the asm volatile, then
>> the both f and g will likely live in some register or memory.
>> The whole point of the construct in the tests is that f has at that spot
>> a reg or mem location, but g isn't present anywhere anymore (as the compiler
>> doesn't or shouldn't know that asm volatile hasn't changed f), thus it
>> should represent them as bswap/clz/ctz/rotate.

> I see.  I'll try to figure out why that didn't work.

So, I tried to duplicate the problem and failed.  The cut&pasto fix
r174632 fixed the only two cases that had failed, on x86_64-linux-gnu
and only at -O1.  I suppose the wrong bit width made the expression
unsuitable for a rotate or debug expr, but the fix made the tests pass
again, so I withdraw the “fixes” for those testcases: they work even
with coalescing fully enabled.  Thanks for catching this.

-- 
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

Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Alexandre Oliva]

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

Ping?  (Updated with improved docs; should the options be renamed to
-ftree-copyrename-* to match the option that covers the entire pass?)

On Jun  4, 2011, Alexandre Oliva <aoliva@redhat.com> wrote:

> On Oct 13, 2009, Alexandre Oliva <aoliva@redhat.com> wrote:
>> On Jun  1, 2009, Alexandre Oliva <aoliva@redhat.com> wrote:
>>> 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.

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

>> On Jun  1, 2009, Alexandre Oliva <aoliva@redhat.com> also wrote:

>>> And the patch below changes the default so that we can optimize more.

>> This patch combines the two patches described above, now that VTA is
>> enabled by default.

> This is an updated version of the patch, adjusting the testcases that
> didn't expect this kind of variable coalescing.

Regstrapped on x86_64-linux-gnu and i686-linux-gnu.  Ok?


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

for  gcc/ChangeLog
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.

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

	* g++.dg/tree-ssa/ivopts-2.C: Adjust for coalescing.
	* gcc.dg/tree-ssa/forwprop-11.c: Likewise.
	* gcc.dg/tree-ssa/ssa-fre-1.c: Likewise.

Index: gcc/common.opt
===================================================================
--- gcc/common.opt.orig	2012-04-08 01:44:00.731983395 -0300
+++ gcc/common.opt	2012-04-08 01:50:38.387224820 -0300
@@ -1926,6 +1926,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(2) RejectNegative Optimization
+Enable coalescing of copy-related user variables that are inlined
+
+ftree-coalesce-vars
+Common Report Var(flag_ssa_coalesce_vars,2) Optimization
+Enable coalescing of all copy-related user 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	2012-04-08 01:44:00.858981874 -0300
+++ gcc/tree-ssa-copyrename.c	2012-04-08 01:50:38.474223779 -0300
@@ -194,20 +194,21 @@ copy_rename_partition_coalesce (var_map 
   ign1 = TREE_CODE (root1) == VAR_DECL && DECL_IGNORED_P (root1);
   ign2 = TREE_CODE (root2) == VAR_DECL && DECL_IGNORED_P (root2);
 
-  /* Never attempt to coalesce 2 user variables unless one is an inline
-     variable.  */
+  /* Refrain from coalescing user variables, if requested.  */
   if (!ign1 && !ign2)
     {
-      if (DECL_FROM_INLINE (root2))
-        ign2 = true;
-      else if (DECL_FROM_INLINE (root1))
+      if (flag_ssa_coalesce_vars && DECL_FROM_INLINE (root2))
+	ign2 = true;
+      else if (flag_ssa_coalesce_vars && DECL_FROM_INLINE (root1))
 	ign1 = true;
-      else
+      else if (flag_ssa_coalesce_vars != 2)
 	{
 	  if (debug)
 	    fprintf (debug, " : 2 different USER vars. No coalesce.\n");
 	  return false;
 	}
+      else
+	ign2 = true;
     }
 
   /* If both values have default defs, we can't coalesce.  If only one has a
Index: gcc/doc/invoke.texi
===================================================================
--- gcc/doc/invoke.texi.orig	2012-04-08 01:44:00.989980308 -0300
+++ gcc/doc/invoke.texi	2012-04-08 01:50:38.846219327 -0300
@@ -404,7 +404,8 @@ Objective-C and Objective-C++ Dialects}.
 -fsplit-ivs-in-unroller -fsplit-wide-types -fstack-protector @gol
 -fstack-protector-all -fstrict-aliasing -fstrict-overflow @gol
 -fthread-jumps -ftracer -ftree-bit-ccp @gol
--ftree-builtin-call-dce -ftree-ccp -ftree-ch -ftree-copy-prop @gol
+-ftree-builtin-call-dce -ftree-ccp -ftree-ch @gol
+-ftree-coalesce-inline-vars -ftree-coalesce-vars -ftree-copy-prop @gol
 -ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse @gol
 -ftree-forwprop -ftree-fre -ftree-loop-if-convert @gol
 -ftree-loop-if-convert-stores -ftree-loop-im @gol
@@ -7434,6 +7435,24 @@ 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
+Tell the copyrename pass (see @option{-ftree-copyrename}) to attempt to
+combine small user-defined variables too, but only if they were inlined
+from other functions.  It is a more limited form of
+@option{-ftree-coalesce-vars}.  This may harm debug information of such
+inlined variables, but it will keep variables of the inlined-into
+function apart from each other, such that they are more likely to
+contain the expected values in a debugging session.  This was the
+default in GCC versions older than 4.7.
+
+@item -ftree-coalesce-vars
+Tell the copyrename pass (see @option{-ftree-copyrename}) to attempt to
+combine small user-defined variables too, instead of just compiler
+temporaries.  This may severely limit the ability to debug an optimized
+program compiled with @option{-fno-var-tracking-assignments}.  In the
+negated form, this flag prevents SSA coalescing of user variables,
+including inlined ones.  This option is enabled by default.
+
 @item -ftree-ter
 @opindex ftree-ter
 Perform temporary expression replacement during the SSA->normal phase.  Single
Index: gcc/testsuite/g++.dg/tree-ssa/ivopts-2.C
===================================================================
--- gcc/testsuite/g++.dg/tree-ssa/ivopts-2.C.orig	2012-04-08 01:44:01.157978296 -0300
+++ gcc/testsuite/g++.dg/tree-ssa/ivopts-2.C	2012-04-08 01:50:38.868219064 -0300
@@ -7,5 +7,5 @@ void test (int *b, int *e, int stride)
       *p = 1;
   }
 
-/* { dg-final { scan-tree-dump-times "PHI <p" 1 "ivopts"} } */
+/* { dg-final { scan-tree-dump-times "PHI <\[pb\]" 1 "ivopts"} } */
 /* { dg-final { cleanup-tree-dump "ivopts" } } */
Index: gcc/testsuite/gcc.dg/tree-ssa/forwprop-11.c
===================================================================
--- gcc/testsuite/gcc.dg/tree-ssa/forwprop-11.c.orig	2012-04-08 01:44:01.249977196 -0300
+++ gcc/testsuite/gcc.dg/tree-ssa/forwprop-11.c	2012-04-08 01:50:38.884218873 -0300
@@ -16,5 +16,5 @@ int g(int *p, int n)
   return q[-1];
 }
 
-/* { dg-final { scan-tree-dump-times "= MEM\\\[\\\(int \\\*\\\)a_.. \\\+ 4B\\\];" 2 "forwprop1" } } */
+/* { dg-final { scan-tree-dump-times "= MEM\\\[\\\(int \\\*\\\)\[ap\]_.. \\\+ 4B\\\];" 2 "forwprop1" } } */
 /* { dg-final { cleanup-tree-dump "forwprop1" } } */
Index: gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-1.c
===================================================================
--- gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-1.c.orig	2012-04-08 01:44:01.429975039 -0300
+++ gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-1.c	2012-04-08 01:50:38.896218729 -0300
@@ -11,5 +11,5 @@ int f(int *a)
   return *c + t;
 }
 
-/* { dg-final { scan-tree-dump "Replaced \\\*c_\[^\n\].*with t_" "fre1" } } */
+/* { dg-final { scan-tree-dump "Replaced \\\*\[ac\]_\[^\n\].*with t_" "fre1" } } */
 /* { dg-final { cleanup-tree-dump "fre1" } } */

[-- 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

Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Alexandre Oliva]

On Apr  9, 2012, Alexandre Oliva <aoliva@redhat.com> wrote:

> On Jun  4, 2011, Alexandre Oliva <aoliva@redhat.com> wrote:

>> On Oct 13, 2009, Alexandre Oliva <aoliva@redhat.com> wrote:
>>> On Jun  1, 2009, Alexandre Oliva <aoliva@redhat.com> wrote:
>>>> 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.

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

>>> On Jun  1, 2009, Alexandre Oliva <aoliva@redhat.com> also wrote:

>>>> And the patch below changes the default so that we can optimize more.

>>> This patch combines the two patches described above, now that VTA is
>>> enabled by default.

>> This is an updated version of the patch, adjusting the testcases that
>> didn't expect this kind of variable coalescing.

> Regstrapped on x86_64-linux-gnu and i686-linux-gnu.  Ok?


> for  gcc/ChangeLog
> 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.

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

> 	* g++.dg/tree-ssa/ivopts-2.C: Adjust for coalescing.
> 	* gcc.dg/tree-ssa/forwprop-11.c: Likewise.
> 	* gcc.dg/tree-ssa/ssa-fre-1.c: Likewise.

> Ping?  (Updated with improved docs; should the options be renamed to
> -ftree-copyrename-* to match the option that covers the entire pass?)

Ping?  http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00412.html

-- 
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

Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables

[Richard Guenther]

On Wed, Jun 13, 2012 at 10:09 AM, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Apr  9, 2012, Alexandre Oliva <aoliva@redhat.com> wrote:
>
>> On Jun  4, 2011, Alexandre Oliva <aoliva@redhat.com> wrote:
>
>>> On Oct 13, 2009, Alexandre Oliva <aoliva@redhat.com> wrote:
>>>> On Jun  1, 2009, Alexandre Oliva <aoliva@redhat.com> wrote:
>>>>> 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.
>
>>>>> VTA doesn't really care which of the 3 possibilities is used, it works
>>>>> equally well with all of them.
>
>>>> On Jun  1, 2009, Alexandre Oliva <aoliva@redhat.com> also wrote:
>
>>>>> And the patch below changes the default so that we can optimize more.
>
>>>> This patch combines the two patches described above, now that VTA is
>>>> enabled by default.
>
>>> This is an updated version of the patch, adjusting the testcases that
>>> didn't expect this kind of variable coalescing.
>
>> Regstrapped on x86_64-linux-gnu and i686-linux-gnu.  Ok?

Ok.

Thanks,
Richard.

>
>> for  gcc/ChangeLog
>> 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.
>
>> for  gcc/testsuite/ChangeLog
>> from  Alexandre Oliva  <aoliva@redhat.com>
>
>>       * g++.dg/tree-ssa/ivopts-2.C: Adjust for coalescing.
>>       * gcc.dg/tree-ssa/forwprop-11.c: Likewise.
>>       * gcc.dg/tree-ssa/ssa-fre-1.c: Likewise.
>
>> Ping?  (Updated with improved docs; should the options be renamed to
>> -ftree-copyrename-* to match the option that covers the entire pass?)
>
> Ping?  http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00412.html
>
> --
> 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