Hi,
On Tue, 11 Sep 2012, Lawrence Crowl wrote:
> change
> node->symbol.whatever
> to
> node->ref_symbol().whatever
Please don't uglify the compiler with this. If GTY deficiencies force you
to do that, then hold off on it until GTY doesn't force you anymore.
Ciao,
Michael.
On 9/12/12, Jan Hubicka wrote:
>> We do not yet seem to have consensus on a long term plan.
>> Would it be reasonable to start on short term prepatory work?
>>
>> In particular, I was think we could do
>>
>>Add converters and testers.
>>Change callers to use those.
>>
>> and maybe
>>
>>
> We do not yet seem to have consensus on a long term plan.
> Would it be reasonable to start on short term prepatory work?
>
> In particular, I was think we could do
>
>Add converters and testers.
>Change callers to use those.
>
> and maybe
>
>Change callers to use type-safe parame
On 2012-09-11 16:22 , Lawrence Crowl wrote:
We do not yet seem to have consensus on a long term plan.
Would it be reasonable to start on short term prepatory work?
In particular, I was think we could do
Add converters and testers.
Change callers to use those.
and maybe
Change call
We do not yet seem to have consensus on a long term plan.
Would it be reasonable to start on short term prepatory work?
In particular, I was think we could do
Add converters and testers.
Change callers to use those.
and maybe
Change callers to use type-safe parameters.
Where those mea
> Sorry to interrupt here, but please finish the existing partial C++
> transitions
> instead of starting to work on new ones. Current stage1 will not last forever
> (stage1 is usually 6 months, so its natural end would be end of September).
> I'd rather have the current transition to a symbol ta
On 9/6/12, Richard Guenther wrote:
> Sorry to interrupt here, but please finish the existing
> partial C++ transitions instead of starting to work on new ones.
> Current stage1 will not last forever (stage1 is usually 6 months,
> so its natural end would be end of September). I'd rather have
> th
On Thu, 6 Sep 2012, Martin Jambor wrote:
> Hi,
>
> (I'm CCing the gcc mailing list too since I suppose it is an accident
> that it wasn't in the message I'm replying to)
>
> On Thu, Sep 06, 2012 at 09:22:27AM +0200, Jan Hubicka wrote:
> > > On Thu, Sep 6, 2012 at 12:08 AM, Jan Hubicka wrote:
>
Hi,
(I'm CCing the gcc mailing list too since I suppose it is an accident
that it wasn't in the message I'm replying to)
On Thu, Sep 06, 2012 at 09:22:27AM +0200, Jan Hubicka wrote:
> > On Thu, Sep 6, 2012 at 12:08 AM, Jan Hubicka wrote:
> > >> > Consequentely you need to track to
> > >> > which
On Thu, Sep 6, 2012 at 12:47 AM, Jan Hubicka wrote:
>> What do you think of the following plan for turning cgraph into
>> a class hierarchy? We cannot finish it until we have gengtype
>> understanding single inheritance, but we can start changing APIs
>> in preparation.
>
> Good you told me, I wa
>
> Areas that are confusing and need clean up (IMO) include:
> 1) handling of aliases and clones
I am slowly cleaning up alias stuff, it had major reorg in 4.7 and further
cleanups in 4.8. Do you have more specific suggestions?
> 2) reachability, needed, analyzed bits. The needed bit is not i
On Wed, Sep 5, 2012 at 10:14 PM, Jan Hubicka wrote:
>> On Wed, Sep 5, 2012 at 5:41 PM, Lawrence Crowl wrote:
>> > On 9/5/12, Xinliang David Li wrote:
>> >> On Sep 5, 2012 Jan Hubicka wrote:
>> >> > OK, the basic idea is that symtab_node is basetype of
>> >> > cgraph_node and varpool_node. We m
> On Wed, Sep 5, 2012 at 5:41 PM, Lawrence Crowl wrote:
> > On 9/5/12, Xinliang David Li wrote:
> >> On Sep 5, 2012 Jan Hubicka wrote:
> >> > OK, the basic idea is that symtab_node is basetype of
> >> > cgraph_node and varpool_node. We may want to drop the historica
> >> > cgraph/varpool names
On Wed, Sep 5, 2012 at 9:38 PM, Jan Hubicka wrote:
>> > On 9/5/12, Xinliang David Li wrote:
>> > > On Sep 5, 2012 Jan Hubicka wrote:
>> > > > OK, the basic idea is that symtab_node is basetype of
>> > > > cgraph_node and varpool_node. We may want to drop the historica
>> > > > cgraph/varpool na
On Wed, Sep 5, 2012 at 9:32 PM, Jan Hubicka wrote:
>> On 9/5/12, Xinliang David Li wrote:
>> > On Sep 5, 2012 Jan Hubicka wrote:
>> > > OK, the basic idea is that symtab_node is basetype of
>> > > cgraph_node and varpool_node. We may want to drop the historica
>> > > cgraph/varpool names here,
On Wed, Sep 5, 2012 at 5:41 PM, Lawrence Crowl wrote:
> On 9/5/12, Xinliang David Li wrote:
>> On Sep 5, 2012 Jan Hubicka wrote:
>> > OK, the basic idea is that symtab_node is basetype of
>> > cgraph_node and varpool_node. We may want to drop the historica
>> > cgraph/varpool names here, since
> > On 9/5/12, Xinliang David Li wrote:
> > > On Sep 5, 2012 Jan Hubicka wrote:
> > > > OK, the basic idea is that symtab_node is basetype of
> > > > cgraph_node and varpool_node. We may want to drop the historica
> > > > cgraph/varpool names here, since function_node/variable_node
> > > > would
>
> The cgraph redesign probably deserves more discussion.
>
> 1) It may be worthwhile to abstract the graph manipulation code into a
> utility class which is templatized.
>
> graph, node with node inheriting from T.
>
> 2) Introduce a global symbol table containing a function table and a
> g
> On 9/5/12, Xinliang David Li wrote:
> > On Sep 5, 2012 Jan Hubicka wrote:
> > > OK, the basic idea is that symtab_node is basetype of
> > > cgraph_node and varpool_node. We may want to drop the historica
> > > cgraph/varpool names here, since function_node/variable_node
> > > would sound bette
On 9/5/12, Xinliang David Li wrote:
> On Sep 5, 2012 Jan Hubicka wrote:
> > OK, the basic idea is that symtab_node is basetype of
> > cgraph_node and varpool_node. We may want to drop the historica
> > cgraph/varpool names here, since function_node/variable_node
> > would sound better. Cgraph st
On 9/5/12, Jan Hubicka wrote:
>> CONVERTERS AND TESTERS ###
>>
>> add
>> symtab_node_base &symtab_node_def::ref_symbol()
>> { return symbol; }
>> symtab_node_base &cgraph_node::ref_symbol()
>> { return symbol; }
>> symtab_node_base &var
On Wed, Sep 5, 2012 at 3:47 PM, Jan Hubicka wrote:
>> What do you think of the following plan for turning cgraph into
>> a class hierarchy? We cannot finish it until we have gengtype
>> understanding single inheritance, but we can start changing APIs
>> in preparation.
>
> Good you told me, I was
> What do you think of the following plan for turning cgraph into
> a class hierarchy? We cannot finish it until we have gengtype
> understanding single inheritance, but we can start changing APIs
> in preparation.
Good you told me, I was about trying that myself. Did not know gengtype
do not und
What do you think of the following plan for turning cgraph into
a class hierarchy? We cannot finish it until we have gengtype
understanding single inheritance, but we can start changing APIs
in preparation.
EXISTING ###
enum symtab_type { SYMTAB_SYMBOL, SY
24 matches
Mail list logo
