public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* RFC: cache uses_template_parms in tree node?
@ 2004-01-22 11:22 Richard Guenther
  2004-01-22 13:24 ` Giovanni Bajo
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Richard Guenther @ 2004-01-22 11:22 UTC (permalink / raw)
  To: gcc; +Cc: Mark Mitchell

Hi!

To address the for_each_template_parm() performance problem, would it be
possible to cache the outcome of uses_template_parms() in the tree
node? Or would this caching somehow be invalidated later?

Just before I start digging into gcc tree's and its wonders :/

Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: cache uses_template_parms in tree node?
  2004-01-22 11:22 RFC: cache uses_template_parms in tree node? Richard Guenther
@ 2004-01-22 13:24 ` Giovanni Bajo
  2004-01-22 13:41   ` Richard Guenther
  2004-01-22 16:18 ` RFC: " Gabriel Dos Reis
  2004-01-22 16:23 ` Mark Mitchell
  2 siblings, 1 reply; 9+ messages in thread
From: Giovanni Bajo @ 2004-01-22 13:24 UTC (permalink / raw)
  To: Richard Guenther, gcc; +Cc: Mark Mitchell, Jan Hubicka

Richard Guenther wrote:

> To address the for_each_template_parm() performance problem, would it
> be possible to cache the outcome of uses_template_parms() in the tree
> node? Or would this caching somehow be invalidated later?
> Just before I start digging into gcc tree's and its wonders :/

To me, the right solution is to get rid of uses_template_parms() altogether. We
can check for type/value dependness instead (we already have functions for
that, and we even cache the outcome in the tree as you are suggesting), so it's
just a matter of removing the old code.

I asked Honza to provide me with some numbers about which calls to
uses_template_parms are the ones most important from a compile-time point of
view. I'm willing to look into this when I get the numbers.

Giovanni Bajo


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: cache uses_template_parms in tree node?
  2004-01-22 13:24 ` Giovanni Bajo
@ 2004-01-22 13:41   ` Richard Guenther
  2004-01-22 15:32     ` Giovanni Bajo
  0 siblings, 1 reply; 9+ messages in thread
From: Richard Guenther @ 2004-01-22 13:41 UTC (permalink / raw)
  To: Giovanni Bajo; +Cc: gcc, Mark Mitchell, Jan Hubicka

On Thu, 22 Jan 2004, Giovanni Bajo wrote:

> Richard Guenther wrote:
>
> > To address the for_each_template_parm() performance problem, would it
> > be possible to cache the outcome of uses_template_parms() in the tree
> > node? Or would this caching somehow be invalidated later?
> > Just before I start digging into gcc tree's and its wonders :/
>
> To me, the right solution is to get rid of uses_template_parms() altogether. We
> can check for type/value dependness instead (we already have functions for
> that, and we even cache the outcome in the tree as you are suggesting), so it's
> just a matter of removing the old code.
>
> I asked Honza to provide me with some numbers about which calls to
> uses_template_parms are the ones most important from a compile-time point of
> view. I'm willing to look into this when I get the numbers.

For a POOMA testcase, a compile with a instrumented compiler yields the
following gprof callgraph for uses_template_parms:

-----------------------------------------------
                                  29             add_friend <cycle 1> [2505]
                                  38             duplicate_decls <cycle 1> [901]
                                  60             get_bindings_real <cycle 1> [2187]
                                 183             make_friend_class <cycle 1> [2376]
                                 201             tsubst_default_arguments <cycle 1> [3660]
                                 212             check_default_argument <cycle 1> [3591]
                                 528             xref_basetypes <cycle 1> [2131]
                                1001             try_one_overload <cycle 1> [2397]
                                1248             grokdeclarator <cycle 1> [484]
                                4720             instantiate_class_template <cycle 1> [628]
                               13723             expand_or_defer_fn <cycle 1> [2108]
                               20135             maybe_retrofit_in_chrg <cycle 1> [1736]
                               22341             unify <cycle 1> [483]
                               50560             register_specialization <cycle 1> [619]
                               51673             tsubst <cycle 1> [281]
                              150936             template_class_depth_real <cycle 1> [1039]
                              152948             tsubst_template_arg <cycle 1> [811]
                              214778             type_unification_real <cycle 1> [911]
                              270505             coerce_template_parms <cycle 1> [398]
                              459713             lookup_template_class <cycle 1> [242]
                0.00    0.00      14/101229133     bt_instantiate_type_proc <cycle 2> [2629]
                0.00    0.00      40/101229133     cp_parser_check_declarator_template_parameters [1881]
[1229]   0.0    0.03    0.00 1415586         uses_template_parms <cycle 1> [1229]
                             1415586             for_each_template_parm <cycle 1> [333]

Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: cache uses_template_parms in tree node?
  2004-01-22 13:41   ` Richard Guenther
@ 2004-01-22 15:32     ` Giovanni Bajo
  0 siblings, 0 replies; 9+ messages in thread
From: Giovanni Bajo @ 2004-01-22 15:32 UTC (permalink / raw)
  To: Richard Guenther; +Cc: gcc, Mark Mitchell, Jan Hubicka

Richard Guenther wrote:

> For a POOMA testcase, a compile with a instrumented compiler yields
> the following gprof callgraph for uses_template_parms:

Thanks! I'm looking into this.

Giovanni Bajo


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: RFC: cache uses_template_parms in tree node?
  2004-01-22 11:22 RFC: cache uses_template_parms in tree node? Richard Guenther
  2004-01-22 13:24 ` Giovanni Bajo
@ 2004-01-22 16:18 ` Gabriel Dos Reis
  2004-01-22 16:23 ` Mark Mitchell
  2 siblings, 0 replies; 9+ messages in thread
From: Gabriel Dos Reis @ 2004-01-22 16:18 UTC (permalink / raw)
  To: Richard Guenther; +Cc: gcc, Mark Mitchell

Richard Guenther <rguenth@tat.physik.uni-tuebingen.de> writes:

| Hi!
| 
| To address the for_each_template_parm() performance problem, would it be
| possible to cache the outcome of uses_template_parms() in the tree
| node? Or would this caching somehow be invalidated later?

It has been agreed (some time ago) that uses_template_parms() should
go away instead of being tweaked.   

-- Gaby

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: RFC: cache uses_template_parms in tree node?
  2004-01-22 11:22 RFC: cache uses_template_parms in tree node? Richard Guenther
  2004-01-22 13:24 ` Giovanni Bajo
  2004-01-22 16:18 ` RFC: " Gabriel Dos Reis
@ 2004-01-22 16:23 ` Mark Mitchell
  2004-01-22 17:00   ` Jan Hubicka
  2 siblings, 1 reply; 9+ messages in thread
From: Mark Mitchell @ 2004-01-22 16:23 UTC (permalink / raw)
  To: Richard Guenther; +Cc: gcc

Richard Guenther wrote:

> Hi!
> 
> To address the for_each_template_parm() performance problem, would it be
> possible to cache the outcome of uses_template_parms() in the tree
> node? Or would this caching somehow be invalidated later?

The right approach, as I've said before, is simply not to *use* 
for_each_template_parm.

It should be unncessary; the right approach should be to use 
type_dependent_p and its friends.

That's not a trivial change, but it's the right change.

There might be a very few places where for_each_template_parm would 
still be necessary -- but they will not be anything that should up on 
the profile.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: RFC: cache uses_template_parms in tree node?
  2004-01-22 16:23 ` Mark Mitchell
@ 2004-01-22 17:00   ` Jan Hubicka
  2004-01-22 17:02     ` Mark Mitchell
  2004-01-24  2:29     ` Mark Mitchell
  0 siblings, 2 replies; 9+ messages in thread
From: Jan Hubicka @ 2004-01-22 17:00 UTC (permalink / raw)
  To: Mark Mitchell; +Cc: Richard Guenther, gcc

> Richard Guenther wrote:
> 
> >Hi!
> >
> >To address the for_each_template_parm() performance problem, would it be
> >possible to cache the outcome of uses_template_parms() in the tree
> >node? Or would this caching somehow be invalidated later?
> 
> The right approach, as I've said before, is simply not to *use* 
> for_each_template_parm.
> 
> It should be unncessary; the right approach should be to use 
> type_dependent_p and its friends.
> 
> That's not a trivial change, but it's the right change.

Mark,
do you think such a change is possible for 3.4 GCC?  If not what would
you recommend to do for the release branch?  The for_each_template_parm
seems to be really one of the major CPU cycle consumers when it come to
C++ compilation and it would be shame to leave it that way for the
release.

Honza
> 
> There might be a very few places where for_each_template_parm would 
> still be necessary -- but they will not be anything that should up on 
> the profile.
> 
> -- 
> Mark Mitchell
> CodeSourcery, LLC
> mark@codesourcery.com

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: RFC: cache uses_template_parms in tree node?
  2004-01-22 17:00   ` Jan Hubicka
@ 2004-01-22 17:02     ` Mark Mitchell
  2004-01-24  2:29     ` Mark Mitchell
  1 sibling, 0 replies; 9+ messages in thread
From: Mark Mitchell @ 2004-01-22 17:02 UTC (permalink / raw)
  To: Jan Hubicka; +Cc: Richard Guenther, gcc

Jan Hubicka wrote:

>>Richard Guenther wrote:
>>
>>
>>>Hi!
>>>
>>>To address the for_each_template_parm() performance problem, would it be
>>>possible to cache the outcome of uses_template_parms() in the tree
>>>node? Or would this caching somehow be invalidated later?
>>
>>The right approach, as I've said before, is simply not to *use* 
>>for_each_template_parm.
>>
>>It should be unncessary; the right approach should be to use 
>>type_dependent_p and its friends.
>>
>>That's not a trivial change, but it's the right change.
> 
> 
> Mark,
> do you think such a change is possible for 3.4 GCC?  If not what would
> you recommend to do for the release branch?  The for_each_template_parm
> seems to be really one of the major CPU cycle consumers when it come to
> C++ compilation and it would be shame to leave it that way for the
> release.

I'm looking into it as we speak.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: RFC: cache uses_template_parms in tree node?
  2004-01-22 17:00   ` Jan Hubicka
  2004-01-22 17:02     ` Mark Mitchell
@ 2004-01-24  2:29     ` Mark Mitchell
  1 sibling, 0 replies; 9+ messages in thread
From: Mark Mitchell @ 2004-01-24  2:29 UTC (permalink / raw)
  To: Jan Hubicka; +Cc: Richard Guenther, gcc

I'm still testing various changes here.

Would one of you mind sending me preprocessed source where 
uses_template_parms shows up high on the profile, so that I can measure 
the improvements I'm getting?

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2004-01-24  2:18 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-22 11:22 RFC: cache uses_template_parms in tree node? Richard Guenther
2004-01-22 13:24 ` Giovanni Bajo
2004-01-22 13:41   ` Richard Guenther
2004-01-22 15:32     ` Giovanni Bajo
2004-01-22 16:18 ` RFC: " Gabriel Dos Reis
2004-01-22 16:23 ` Mark Mitchell
2004-01-22 17:00   ` Jan Hubicka
2004-01-22 17:02     ` Mark Mitchell
2004-01-24  2:29     ` Mark Mitchell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).