headers
Jan Hubicka | 1 Jun 2005 01:08
Picon

[RFC] Early inlining pass


Hi,
this patch adds early inlining pass that inline the "obvious" stuff (ie
functions having body smaller than the call construct and always inline
functions).  This is followed by cleanup_cfg and true inlining pass.

This helps in scenarios:
 1) With tree profiling we no longer have counter per each inlined call.
    This makes surprising difference in tramp3d where we have few hounders
    dummy call for each usefull instruction executed, so execution times with
    -fprofile-generate -ftree-based-profiling goes down from 10minutes to 6
    seconds, RTL profiling is at 4.5 seconds.
 2) Inlining of body we already inlined into is slightly cheaper than inlining
    inlining the body and it's callers all the time.  This seems to account by
    up to 11% compile time difference for Gerald's testcase (but inlining
    decisions are affected too so it is dificult to judge, performance and code
    size however remains (almost) unchanged.  It also seems to account in SPEC
    build and GCC bootstrap as bootstrap time seems improved by about 30-100
    seconds (even if this close to noise factor).
 3) We have better chances that pre-inline optimization would be usefull for
    C++.  I experimented with this on tree-profiling branch and while it does
    resonable (ie measurable) job for SPEC2000, it is hardly usefull for C++
    as the tiny functions are almost unoptimizable in isolation.

And now the problems - I am not sure how to interface properly to the IPA pm.
At the moment I have pass early_local_passes that is IPA pass and the local
passes (profiling and cleanup_cfg currently) are run as it's subpasses. I am
letting passmanger to switch from IPA to non-IPA by iterating over all
functions whenever there is subpass of any IPA pass.  I am not sure if this is
way we want to go (perhaps we might add some IPA property to make this
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jan Hubicka | 1 Jun 2005 01:12
Picon

Kill some dead fields

Hi,
I am going to commit this as obvious once libjava bootstraps again....

Honza

2005-06-01  Jan Hubicka  <jh <at> suse.cz>
	* except.c (struct eh_region): Kill unused fields.
	* basic-block.h (struct basic_block_def): Likewise.
Index: except.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/except.c,v
retrieving revision 1.307
diff -c -3 -p -r1.307 except.c
*** except.c	27 May 2005 22:50:41 -0000	1.307
--- except.c	31 May 2005 20:29:56 -0000
*************** struct eh_region GTY(())
*** 150,157 ****
      struct eh_region_u_try {
        struct eh_region *catch;
        struct eh_region *last_catch;
-       struct eh_region *prev_try;
-       rtx continue_label;
      } GTY ((tag ("ERT_TRY"))) try;

      /* The list through the catch handlers, the list of type objects
--- 150,155 ----
*************** struct eh_region GTY(())
*** 180,192 ****
      struct eh_region_u_cleanup {
        struct eh_region *prev_try;
(Continue reading)

Permalink | Reply | 2 comments |
headers
Richard Henderson | 1 Jun 2005 01:22
Picon
Favicon

Re: [PATCH]: Move DECL_DEBUG_EXPR to a hashtable

On Mon, May 30, 2005 at 08:35:19PM -0400, Daniel Berlin wrote:
> 	* c-objc-common.c (c_tree_printer): Check flag before hashtable.
> 	Use GET_DECL_DEBUG_EXPR and SET_DECL_DEBUG_EXPR.
> 	* dwarf2out.c (dwarf2out_var_location): Ditto.
> 	* toplev.c (default_tree_printer): Ditto.
> 	* tree-outof-ssa.c (create_temp): Ditto.
> 	* tree-sra.c (instantiate_element): Ditto.
> 	* var-tracking.c (track_expr_p): Ditto.
> 	* tree.c (struct tree_map): New structure.
> 	(debug_expr_for_decl): New.
> 	(tree_map_eq): New function.
> 	(tree_map_hash): Ditto.
> 	(tree_map_marked_p): Ditto.
> 	(print_debug_expr_statistics): Ditto.
> 	(decl_debug_expr_lookup): Ditto.
> 	(decl_debug_expr_insert): Ditto.
> 	(dump_tree_statistics): Dump debug_expr hashtable stats.
> 	* tree.h (DECL_DEBUG_EXPR): Remove.
> 	(GET_DECL_DEBUG_EXPR): Add.
> 	(SET_DECL_DEBUG_EXPR): Ditto.

Current practice is to use FOO and SET_FOO, not GET_FOO and SET_FOO.
Ok with that change.

r~
Permalink | Reply | 0 comments |
headers
Richard Henderson | 1 Jun 2005 01:24
Picon
Favicon

Re: Kill some dead fields

On Wed, Jun 01, 2005 at 01:12:52AM +0200, Jan Hubicka wrote:
> -     } GTY ((tag ("ERT_FIXUP"))) fixup;

You should be removing ERT_FIXUP as well.  Perhaps some other
things related to fixups; I havn't done a search.

r~
Permalink | Reply | 1 comment |
headers
Jan Hubicka | 1 Jun 2005 01:27
Picon

Re: Kill some dead fields

> On Wed, Jun 01, 2005 at 01:12:52AM +0200, Jan Hubicka wrote:
> > -     } GTY ((tag ("ERT_FIXUP"))) fixup;
> 
> You should be removing ERT_FIXUP as well.  Perhaps some other
> things related to fixups; I havn't done a search.

OK, there seems to be only dumping facility left, so I will kill it as
well.
Thanks,
Honza
> 
> 
> r~
Permalink | Reply | 0 comments |
headers
Jan Hubicka | 1 Jun 2005 01:31
Picon

Re: [rfc] Whole program optimization

> On Thu, May 26, 2005 at 06:46:33PM -0700, Geoffrey Keating wrote:
> > > I remember that we discussed this with Richard while past and Richard
> > > argued that ELF visibility flags should be used instead.  I don't have
> > > archive of the disucssion and I am not quite convinced that this is
> > > possible (this is quite ortoghonal issue to the visibility outside
> > > linked object), so if I miss something here, please enlighten me.
> > 
> > I believe that the idea here was that instead of
> > __attribute__((used)), you would use
> > __attribute__((visibility("default"))) or
> > __attribute__((visibility("hidden"))) or
> > __attribute__((visibility("protected"))).  That is, this new functionality
> > would be equivalent to saying -fvisibility=internal.
> 
> Indeed.  The point is that we have existing options to control
> visibility of symbols.  We do not need another.
OK,
here is updated patch that makes unit-at-a-time to thread
VISIBILITY_INTERNAL symbols same way as it used to do with globals and
-fwhole-program.  It breaks two testcases however:

g++.dg/ext/visibility/pragma-override1.C scan-assembler \\\\.internal.*Foo.methodEv
g++.dg/ext/visibility/pragma-override2.C scan-assembler \\\\.internal.*Foo.methodEv

Since these are emitted as statics now.  I am not quite sure if we want
to restore them somehow.

If this seems to make sense, I will proceed with the plan outlined -
making -fvisibility=internal supported on non-ELF systems and
unit-at-a-time mode and making main function immune to any -fvisibility
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mike Stump | 1 Jun 2005 01:33
Picon
Favicon

Re: Avoid running non-portable testcases

On May 27, 2005, at 1:10 PM, Janis Johnson wrote:
> What are the new TCL dependencies, and which version do they require?

ERROR: obj-c++.dg/method-11.mm: error executing dg-final: bad option  
"map": must be compare, first, index, last, length, match, range,  
tolower, toupper, trim, trimleft, trimright, wordend, or wordstart

http://lists.gnu.org/archive/html/dejagnu/2004-03/msg00058.html
http://gcc.gnu.org/ml/java-patches/2003-q1/msg00429.html
http://gcc.gnu.org/ml/java-patches/2003-q1/msg00430.html
http://gcc.gnu.org/ml/java-patches/2003-q1/msg00436.html

mrs $ runtest --version
WARNING: Couldn't find the global config file.
Expect version is       5.42.0
Tcl version is          8.4
Framework version is    1.4.4

I wish we could poison newer tcl features!  The good news is that  
this I think is the only non-portable to older tcl issue.
Permalink | Reply | 0 comments |
headers
Zack Weinberg | 1 Jun 2005 01:44

Re: [PATCH]: Move DECL_DEBUG_EXPR to a hashtable


RTH having gotten to the approval before me, I'd just like to point
out that the decl_die_table in dwarf2out.c could probably be turned
into a tree_map.

zw
Permalink | Reply | 1 comment |
headers
Paolo Carlini | 1 Jun 2005 02:00
Picon

Re: Problems with PR 21210

Mark Mitchell wrote:

> The conversion to "S" requires a constructor call, which is usually
> considered worse than a "standard conversion" (like converting from
> "int" to "double").  So, that's why I think we should call the second "f".

Well, you carefully avoided to tell me, but currently we *are* calling
the *first* "f"... ;)

This doesn't mean I'm not seeing your point of course, but maybe we
don't really want to have the "right" overloading *now*, when things are
still up in the air about C++ vs C99...

In my understanding we should do our best to allow people to keep on
using __complex__ together with std::complex in the way they are used to
do. At the same time we should not try too achieve too much *now*. In
this context, Jason proposal seems naively right to me, in the sense
that seems to me "conservative": given the *current* standard how
possibly an extension like __complex__ can be preferred to a builtin type?

More generally, if Jason proposal is considered too risky a choice from
the point of view of the future evolution of C++, I would suggest to
stay as close as possible to the behavior of 3.4.x. To my best
knowledge, not many people complained. I would venture to say, no-one
complained about the behavior of vector<__complex__> and
std::complex(__complex__)...

Paolo.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Berlin | 1 Jun 2005 02:03

Re: [PATCH]: Move DECL_DEBUG_EXPR to a hashtable

On Tue, 2005-05-31 at 16:44 -0700, Zack Weinberg wrote:
> RTH having gotten to the approval before me, I'd just like to point
> out that the decl_die_table in dwarf2out.c could probably be turned
> into a tree_map.
> 
> zw

I may get to that eventually, however, my main impetus is because i know
getting rid of fields for DECL_DEBUG_EXPR and DECL_VALUE_EXPR reduces a
lot of tree structures 8 bytes in the new scheme, and causes a noticable
speedup :)
Permalink | Reply | 0 comments |

Gmane