il_duplicate): likewise, convert to...
(tracer_state::tail_duplicate): ...this
(tracer): introduce tracer_state instance to move state within
the pass from being global to being on the stack
commit a5aea6ce6802fa3d74a8a801cd7809869a63a96a
Author: David Malcolm
Date: Wed May 22 06:20:30
(restarting this thread:
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01318.html )
On Thu, 2013-05-23 at 13:51 -0700, Richard Henderson wrote:
> On 05/23/2013 12:06 PM, Richard Henderson wrote:
> > Another thing I should mention while you're doing all of these static
> > function
> > to class mem
On 07/01/2013 12:59 PM, David Malcolm wrote:
> I tried this approach for tracer, but there were non-trivial differences
> between the old and new tracer.o files, enough to make me uncomfortable
> with this approach.
Like what? Are these just bugs in the IPA-CP pass failing to propagate? If
so, w
On Wed, May 22, 2013 at 08:45:45PM -0400, David Malcolm wrote:
> I'm attempting to eliminate global state from the insides of gcc.
>
> gcc/tracer.c has various global variables, which are only used during
> the lifetime of the execute callback of that pass, and cleaned up at the
> end of each invo
On Thu, 2013-05-23 at 07:14 +0200, Jakub Jelinek wrote:
> On Wed, May 22, 2013 at 08:45:45PM -0400, David Malcolm wrote:
> > I'm attempting to eliminate global state from the insides of gcc.
> >
> > gcc/tracer.c has various global variables, which are only used during
> > the lifetime of the execu
On Thu, 2013-05-23 at 06:56 -0400, David Malcolm wrote:
> On Thu, 2013-05-23 at 07:14 +0200, Jakub Jelinek wrote:
> > On Wed, May 22, 2013 at 08:45:45PM -0400, David Malcolm wrote:
> > > I'm attempting to eliminate global state from the insides of gcc.
> > >
> > > gcc/tracer.c has various global v
On 05/23/2013 03:56 AM, David Malcolm wrote:
> The idea is to use (and then not use) C++'s "static" syntax for class
> methods and fields. By making that optional with a big configure-time
> switch, it gives us a way of making state be either global vs on-stack,
> with minimal syntax changes.
Pla
On Thu, May 23, 2013 at 12:06:01PM -0700, Richard Henderson wrote:
> > struct foo_c_state
> > {
> > some_type bar;
> > };
> > # define bar ctxt->x_foo_c_bar;
> > /* there's a"context *ctxt;" variable somewhere, possibly
> >using TLS */
>
> I've an idea that this will perform very badly
On 05/23/2013 12:20 PM, Jakub Jelinek wrote:
> On Thu, May 23, 2013 at 12:06:01PM -0700, Richard Henderson wrote:
>>> struct foo_c_state
>>> {
>>> some_type bar;
>>> };
>>> # define bar ctxt->x_foo_c_bar;
>>> /* there's a"context *ctxt;" variable somewhere, possibly
>>>using TLS */
>>
>
On Thu, 2013-05-23 at 11:59 -0400, David Malcolm wrote:
> On Thu, 2013-05-23 at 06:56 -0400, David Malcolm wrote:
> > On Thu, 2013-05-23 at 07:14 +0200, Jakub Jelinek wrote:
> > > On Wed, May 22, 2013 at 08:45:45PM -0400, David Malcolm wrote:
> > > > I'm attempting to eliminate global state from th
> /* The Ith entry is the number of objects on a page or order I. */
>
> -static unsigned objects_per_page_table[NUM_ORDERS];
> +DEFINE_STATIC_STATE_ARRAY(unsigned, objects_per_page_table, NUM_ORDERS)
>
> /* The Ith entry is the size of an object on a page of order I. */
>
> -static size_
On 05/23/2013 02:31 PM, Richard Henderson wrote:
I think we need more weigh in from other maintainers on this, rather than
iterating a 5th time today...
This seems like an awful lot of pain.
I don't think we should be looking to generate different code for
library vs executable GCC.
I thin
On Thu, 2013-05-23 at 13:31 -0700, Richard Henderson wrote:
> > /* The Ith entry is the number of objects on a page or order I. */
> >
> > -static unsigned objects_per_page_table[NUM_ORDERS];
> > +DEFINE_STATIC_STATE_ARRAY(unsigned, objects_per_page_table, NUM_ORDERS)
> >
> > /* The Ith entr
On 05/23/2013 12:06 PM, Richard Henderson wrote:
> Another thing I should mention while you're doing all of these static function
> to class member conversions is that as written we're losing target-specific
> optimizations that can be done on purely local functions. This is trivially
> fixed by p
On Thu, May 23, 2013 at 02:44:48PM -0600, Jeff Law wrote:
> On 05/23/2013 02:31 PM, Richard Henderson wrote:
> >I think we need more weigh in from other maintainers on this, rather than
> >iterating a 5th time today...
> This seems like an awful lot of pain.
>
> I don't think we should be looking
On 05/23/2013 02:59 PM, Jakub Jelinek wrote:
On Thu, May 23, 2013 at 02:44:48PM -0600, Jeff Law wrote:
On 05/23/2013 02:31 PM, Richard Henderson wrote:
I think we need more weigh in from other maintainers on this, rather than
iterating a 5th time today...
This seems like an awful lot of pain.
On Thu, May 23, 2013 at 11:42 PM, Jeff Law wrote:
> On 05/23/2013 02:59 PM, Jakub Jelinek wrote:
>>
>> On Thu, May 23, 2013 at 02:44:48PM -0600, Jeff Law wrote:
>>>
>>> On 05/23/2013 02:31 PM, Richard Henderson wrote:
I think we need more weigh in from other maintainers on this, rather
>
17 matches
Mail list logo
