Re: Cgraph Modification Plan
> > 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 in sync > with the call to check if a function is needed. Bits and attributes > used in analysis should be isolated out from the core data structure. This is mostly done. Reachable and needed flags are removed. We still have analyzed flag, but it really has meaning "is definition" these days except for early cgraph construction phase, so I intend to rename it (and make cgraph construction to use its own bitmap). > 3) ipa references -- should they be modeled as special edges? They are special edges. Different in memory from cgraph edges though. I did some estimates how much memory would be needed for representing them by the cgraph_edge way and it was quite steep for Mozilla LTO (over a gig, as compared to about 200MB we need now). We could also rework cgraph edges into vector represnetaiton instead of doubly linked lists to save some memory, not sure how fruitful that would be. Still different sizes of in memory representations and thus different vectors is desirable here. > > >> > >> > > >> >> 2) Introduce a global symbol table containing a function table > >> >> and a global variable table. The function table should replace > >> >> the current cgraph node link list, and the variable table replaces > >> >> the varpool. The symbol table should provide basic interfaces to > >> >> do named based lookup, traversal, alias handling etc. I noticed > >> >> trunk already has some of that -- but it seems more abstraction > >> >> is needed. > >> > > >> > Do you mean moving away from a pointer-based approach? > >> > >> See above. I mean it is important to have well defined symtab > >> interfaces that hide implementation as much as possible. It will make > >> the interfaces more stable. It is currently quite difficult for > >> cgraph/varpool related changes in gcc branches to keep up with trunk > >> without stable core APIs. > > > > Well, the APIs did not changed much over years (LTO brought in some more > > busy > > changes, but many were just hacks that needed redesign anyway), in 4.8 we > > changed quite a lot because of introduction of the symbol table. It would be > > really nice to get as much as C++ conversion into 4.8, too, since we broke > > most > > of existing patches anyway, to get more stability frm 4.9 up. > > > >> >> 3) it seems natural to drop 'node' in the naming scheme > >> >> > >> >> symbol (symtab_entry) --> base class; > >> >> function --> derived from symbol; (It conflicts with the existing > >> >> struct function though); > >> >> variable --> derived from symbol; > >> >> > >> >> typedef node cnode; > >> > > >> > A node is not a derived class of node even when > >> > function is derived from symbol. That property is helpful in > >> > ensuring usable type safety. > >> > >> > >> We don't need node -- only node is needed, and it is > >> derived from function and function is derived from symbol. > > > > Yes, this is where I expected to land. I expect to see more complex > > inheritance > > tree. Currently we have: > > > > symbol > > | > > +-function (cgraph) > > | > > +-variable (varpool) > > > > While function can have five types - just external declarations, actual > > definitions with body (analyzed flag is set), thunk, alias and virtual clone > > > > Similarly variables are declarations, ones with body (analyzed flag is set), > > and aliases. > > > > We do not represent labels and const_decl references. We ought: those are > > also > > symbols and they are important for partitioning. > > > > We probably want rither structure here in longer term: > > > > symbol > > | > > +-function declaration > > | | > > | +-function definition > > | | > > | +-function alternative entry point (thunk) > > | | > > | +-function alias > > | | > > | +-virtual clone > > | > > +-variable declaration > > | | > > | +-variable definition (possibly constant pool references via const_decl > > here, too) > > | | > > | +-variable alias > > | > > +-function label definition > > > > In particular we do not want to store all the stuff we store for function > > definitions for declarations. > > True, but that is at the cost of too complex class hierarchy. Is it > enough to have 'has_body()' to differentiate def vs declarations (the > meaning of 'is_external' is overloaded)? The additional information > can be accessed via indirection (to additional data structure). We can, not sure how effective those sparse tables will be in practice however, Some of this stuff is quite critical during WPA stage. > > For aliases, why can't those nodes be merged into one node (mapped > from all assembler names in the symtab)? aliases will just be > attribute of the symbol). I attempted to
Re: Cgraph Modification Plan
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 may want to drop the historica >> >> > cgraph/varpool names here, since function_node/variable_node >> >> > would sound better. Cgraph still exists, but varpool is more >> >> > or less historical relic. >> >> >> >> The cgraph redesign probably deserves more discussion. >> > >> > Hence, the post! >> > >> >> 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. >> > >> > While I won't dispute the statement, getting from here to there >> > will likely involve some intermediate steps. >> >> Yes. My point is that the intermediate steps should be driven by the >> final goal. It is important to first have the design of final class >> hierarchy and interfaces nailed and then the intermediate steps >> defined instead of the other way around. > > Yes, it seems resonable to me. We just need to keep in mind the specifics > callgraph has (i.e. many types of edges that are relevant in different > contextes and have good reason for different kind of in memory > reppresentation) > There are also different types of nodes - functions, variables, aliases. I > plan > to add labels in 4.8 timeframe, too). Areas that are confusing and need clean up (IMO) include: 1) handling of aliases and clones 2) reachability, needed, analyzed bits. The needed bit is not in sync with the call to check if a function is needed. Bits and attributes used in analysis should be isolated out from the core data structure. 3) ipa references -- should they be modeled as special edges? >> >> > >> >> 2) Introduce a global symbol table containing a function table >> >> and a global variable table. The function table should replace >> >> the current cgraph node link list, and the variable table replaces >> >> the varpool. The symbol table should provide basic interfaces to >> >> do named based lookup, traversal, alias handling etc. I noticed >> >> trunk already has some of that -- but it seems more abstraction >> >> is needed. >> > >> > Do you mean moving away from a pointer-based approach? >> >> See above. I mean it is important to have well defined symtab >> interfaces that hide implementation as much as possible. It will make >> the interfaces more stable. It is currently quite difficult for >> cgraph/varpool related changes in gcc branches to keep up with trunk >> without stable core APIs. > > Well, the APIs did not changed much over years (LTO brought in some more busy > changes, but many were just hacks that needed redesign anyway), in 4.8 we > changed quite a lot because of introduction of the symbol table. It would be > really nice to get as much as C++ conversion into 4.8, too, since we broke > most > of existing patches anyway, to get more stability frm 4.9 up. > >> >> 3) it seems natural to drop 'node' in the naming scheme >> >> >> >> symbol (symtab_entry) --> base class; >> >> function --> derived from symbol; (It conflicts with the existing >> >> struct function though); >> >> variable --> derived from symbol; >> >> >> >> typedef node cnode; >> > >> > A node is not a derived class of node even when >> > function is derived from symbol. That property is helpful in >> > ensuring usable type safety. >> >> >> We don't need node -- only node is needed, and it is >> derived from function and function is derived from symbol. > > Yes, this is where I expected to land. I expect to see more complex > inheritance > tree. Currently we have: > > symbol > | > +-function (cgraph) > | > +-variable (varpool) > > While function can have five types - just external declarations, actual > definitions with body (analyzed flag is set), thunk, alias and virtual clone > > Similarly variables are declarations, ones with body (analyzed flag is set), > and aliases. > > We do not represent labels and const_decl references. We ought: those are also > symbols and they are important for partitioning. > > We probably want rither structure here in longer term: > > symbol > | > +-function declaration > | | > | +-function definition > | | > | +-function alternative entry point (thunk) > | | > | +-function alias > | | > | +-virtual clone > | > +-variable declaration > | | > | +-variable definition (possibly constant pool references via const_decl > here, too) > | | > | +-variable alias > | > +-function label definition > > In particular we do not want to store all the stuff we store for function > definitions for declarations. True, but that is at the cost of too complex class hierarchy. Is it enough to have 'has_body()' to differentiate def vs declarations (the meaning of 'is_external' is overloaded)? The additional
Re: Cgraph Modification Plan
> 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 function_node/variable_node
> >> > would sound better. Cgraph still exists, but varpool is more
> >> > or less historical relic.
> >>
> >> The cgraph redesign probably deserves more discussion.
> >
> > Hence, the post!
> >
> >> 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.
> >
> > While I won't dispute the statement, getting from here to there
> > will likely involve some intermediate steps.
>
> Yes. My point is that the intermediate steps should be driven by the
> final goal. It is important to first have the design of final class
> hierarchy and interfaces nailed and then the intermediate steps
> defined instead of the other way around.
Yes, it seems resonable to me. We just need to keep in mind the specifics
callgraph has (i.e. many types of edges that are relevant in different
contextes and have good reason for different kind of in memory reppresentation)
There are also different types of nodes - functions, variables, aliases. I plan
to add labels in 4.8 timeframe, too).
>
> >
> >> 2) Introduce a global symbol table containing a function table
> >> and a global variable table. The function table should replace
> >> the current cgraph node link list, and the variable table replaces
> >> the varpool. The symbol table should provide basic interfaces to
> >> do named based lookup, traversal, alias handling etc. I noticed
> >> trunk already has some of that -- but it seems more abstraction
> >> is needed.
> >
> > Do you mean moving away from a pointer-based approach?
>
> See above. I mean it is important to have well defined symtab
> interfaces that hide implementation as much as possible. It will make
> the interfaces more stable. It is currently quite difficult for
> cgraph/varpool related changes in gcc branches to keep up with trunk
> without stable core APIs.
Well, the APIs did not changed much over years (LTO brought in some more busy
changes, but many were just hacks that needed redesign anyway), in 4.8 we
changed quite a lot because of introduction of the symbol table. It would be
really nice to get as much as C++ conversion into 4.8, too, since we broke most
of existing patches anyway, to get more stability frm 4.9 up.
> >> 3) it seems natural to drop 'node' in the naming scheme
> >>
> >> symbol (symtab_entry) --> base class;
> >> function --> derived from symbol; (It conflicts with the existing
> >> struct function though);
> >> variable --> derived from symbol;
> >>
> >> typedef node cnode;
> >
> > A node is not a derived class of node even when
> > function is derived from symbol. That property is helpful in
> > ensuring usable type safety.
>
>
> We don't need node -- only node is needed, and it is
> derived from function and function is derived from symbol.
Yes, this is where I expected to land. I expect to see more complex inheritance
tree. Currently we have:
symbol
|
+-function (cgraph)
|
+-variable (varpool)
While function can have five types - just external declarations, actual
definitions with body (analyzed flag is set), thunk, alias and virtual clone
Similarly variables are declarations, ones with body (analyzed flag is set),
and aliases.
We do not represent labels and const_decl references. We ought: those are also
symbols and they are important for partitioning.
We probably want rither structure here in longer term:
symbol
|
+-function declaration
| |
| +-function definition
| |
| +-function alternative entry point (thunk)
| |
| +-function alias
| |
| +-virtual clone
|
+-variable declaration
| |
| +-variable definition (possibly constant pool references via const_decl
here, too)
| |
| +-variable alias
|
+-function label definition
In particular we do not want to store all the stuff we store for function
definitions for declarations.
variable/function aliases do have a lot in common (similarly for
function/variable definitions), too. The reason why I did not introduce
separate alias_node type is that function aliases are different from variable
aliases in several ways. For example, they can not be destinations of function
calls.
>
> >
> >> 4) coding convention is needed for functions that do 'casting'
> >> and 'trial casting'.
> >
> > The functions I have suggestion are ptr_... and try_... respectively.
> > Are you suggesting amending the coding conventions?
> >
>
> Is this something agreed upon in previous discussions or something
> newly brought up? How about using template function in base to do
> casting:
>
> trial cast:
>
> template T* symbol::cast_to(symbol* p) {
>if (p->is())
>
Re: Cgraph Modification Plan
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 names here, since function_node/variable_node >> > > > would sound better. Cgraph still exists, but varpool is more >> > > > or less historical relic. >> > > >> > > The cgraph redesign probably deserves more discussion. >> > >> > Hence, the post! >> > >> > > 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. >> > >> > While I won't dispute the statement, getting from here to there >> > will likely involve some intermediate steps. >> >> Commonizing some of cfg/cgraph/ssa graph handling would not hurt, but >> there is not _that_ much code in common - we do some strongly connected >> components discovery on all three kinds of graphs and basic traversals. > > Also note that symbol table realy is an oriented multigraph with different > types of edges (i.e. calls and references and eventualy we will have indirect > calls with mutiple possible destinations derrived from PTA and > devirtualization > logic). yes, but additional edge properties can also be abstracted away by using template parameters. David > > Honza
Re: Cgraph Modification Plan
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, since function_node/variable_node >> > > would sound better. Cgraph still exists, but varpool is more >> > > or less historical relic. >> > >> > The cgraph redesign probably deserves more discussion. >> >> Hence, the post! >> >> > 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. >> >> While I won't dispute the statement, getting from here to there >> will likely involve some intermediate steps. > > Commonizing some of cfg/cgraph/ssa graph handling would not hurt, but > there is not _that_ much code in common - we do some strongly connected > components discovery on all three kinds of graphs and basic traversals. >> Once we have the common infrastructure for graphs, new uses will be easily created (e.g, dynamic callgraph in profile-gen runtime analysis, module graph, etc) -- graph is one of the most basic data structures for compilers. David >> > 2) Introduce a global symbol table containing a function table >> > and a global variable table. The function table should replace >> > the current cgraph node link list, and the variable table replaces >> > the varpool. The symbol table should provide basic interfaces to >> > do named based lookup, traversal, alias handling etc. I noticed >> > trunk already has some of that -- but it seems more abstraction >> > is needed. >> >> Do you mean moving away from a pointer-based approach? > > I would say that trunk now have what is described here. I still plan to unify > some of code (like alias handling) that is split for historical reasons, but > those are mostly cleanups still intended for 4.8. > > Honza
Re: Cgraph Modification Plan
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 function_node/variable_node
>> > would sound better. Cgraph still exists, but varpool is more
>> > or less historical relic.
>>
>> The cgraph redesign probably deserves more discussion.
>
> Hence, the post!
>
>> 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.
>
> While I won't dispute the statement, getting from here to there
> will likely involve some intermediate steps.
Yes. My point is that the intermediate steps should be driven by the
final goal. It is important to first have the design of final class
hierarchy and interfaces nailed and then the intermediate steps
defined instead of the other way around.
>
>> 2) Introduce a global symbol table containing a function table
>> and a global variable table. The function table should replace
>> the current cgraph node link list, and the variable table replaces
>> the varpool. The symbol table should provide basic interfaces to
>> do named based lookup, traversal, alias handling etc. I noticed
>> trunk already has some of that -- but it seems more abstraction
>> is needed.
>
> Do you mean moving away from a pointer-based approach?
See above. I mean it is important to have well defined symtab
interfaces that hide implementation as much as possible. It will make
the interfaces more stable. It is currently quite difficult for
cgraph/varpool related changes in gcc branches to keep up with trunk
without stable core APIs.
>
>> 3) it seems natural to drop 'node' in the naming scheme
>>
>> symbol (symtab_entry) --> base class;
>> function --> derived from symbol; (It conflicts with the existing
>> struct function though);
>> variable --> derived from symbol;
>>
>> typedef node cnode;
>
> A node is not a derived class of node even when
> function is derived from symbol. That property is helpful in
> ensuring usable type safety.
We don't need node -- only node is needed, and it is
derived from function and function is derived from symbol.
>
>> 4) coding convention is needed for functions that do 'casting'
>> and 'trial casting'.
>
> The functions I have suggestion are ptr_... and try_... respectively.
> Are you suggesting amending the coding conventions?
>
Is this something agreed upon in previous discussions or something
newly brought up? How about using template function in base to do
casting:
trial cast:
template T* symbol::cast_to(symbol* p) {
if (p->is())
return static_cast(p);
return 0;
}
cast:
template T& symbol:as(symbol* p) {
assert(p->is())
return static_cast(*p);
}
David
> --
> Lawrence Crowl
Re: Cgraph Modification Plan
> > 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 still exists, but varpool is more > > > > or less historical relic. > > > > > > The cgraph redesign probably deserves more discussion. > > > > Hence, the post! > > > > > 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. > > > > While I won't dispute the statement, getting from here to there > > will likely involve some intermediate steps. > > Commonizing some of cfg/cgraph/ssa graph handling would not hurt, but > there is not _that_ much code in common - we do some strongly connected > components discovery on all three kinds of graphs and basic traversals. Also note that symbol table realy is an oriented multigraph with different types of edges (i.e. calls and references and eventualy we will have indirect calls with mutiple possible destinations derrived from PTA and devirtualization logic). Honza
Re: Cgraph Modification Plan
> > 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 > global variable table. The function table should replace the current > cgraph node link list, and the variable table replaces the varpool. > The symbol table should provide basic interfaces to do named based > lookup, traversal, alias handling etc. I noticed trunk already has > some of that -- but it seems more abstraction is needed. > > 3) it seems natural to drop 'node' in the naming scheme > > symbol (symtab_entry) --> base class; > function --> derived from symbol; (It conflicts with the existing > struct function though); > variable --> derived from symbol; > > typedef node cnode; We could drop node, yes. The conflict with current function is more interesting. Basically symbol table "function" is that we need for IPA optimizations, while struct function is what is load when function body is needed. Those are different. Not sure if we don't want to have symtab_ prefix for all symbol table stuff or if we want to rename struct function into something more fit. Honza
Re: Cgraph Modification Plan
> 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 still exists, but varpool is more > > > or less historical relic. > > > > The cgraph redesign probably deserves more discussion. > > Hence, the post! > > > 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. > > While I won't dispute the statement, getting from here to there > will likely involve some intermediate steps. Commonizing some of cfg/cgraph/ssa graph handling would not hurt, but there is not _that_ much code in common - we do some strongly connected components discovery on all three kinds of graphs and basic traversals. > > > 2) Introduce a global symbol table containing a function table > > and a global variable table. The function table should replace > > the current cgraph node link list, and the variable table replaces > > the varpool. The symbol table should provide basic interfaces to > > do named based lookup, traversal, alias handling etc. I noticed > > trunk already has some of that -- but it seems more abstraction > > is needed. > > Do you mean moving away from a pointer-based approach? I would say that trunk now have what is described here. I still plan to unify some of code (like alias handling) that is split for historical reasons, but those are mostly cleanups still intended for 4.8. Honza
Re: Cgraph Modification Plan
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 still exists, but varpool is more > > or less historical relic. > > The cgraph redesign probably deserves more discussion. Hence, the post! > 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. While I won't dispute the statement, getting from here to there will likely involve some intermediate steps. > 2) Introduce a global symbol table containing a function table > and a global variable table. The function table should replace > the current cgraph node link list, and the variable table replaces > the varpool. The symbol table should provide basic interfaces to > do named based lookup, traversal, alias handling etc. I noticed > trunk already has some of that -- but it seems more abstraction > is needed. Do you mean moving away from a pointer-based approach? > 3) it seems natural to drop 'node' in the naming scheme > > symbol (symtab_entry) --> base class; > function --> derived from symbol; (It conflicts with the existing > struct function though); > variable --> derived from symbol; > > typedef node cnode; A node is not a derived class of node even when function is derived from symbol. That property is helpful in ensuring usable type safety. > 4) coding convention is needed for functions that do 'casting' > and 'trial casting'. The functions I have suggestion are ptr_... and try_... respectively. Are you suggesting amending the coding conventions? -- Lawrence Crowl
Re: Cgraph Modification Plan
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 &varpool_node::ref_symbol()
>> { return symbol; }
>>
>> change
>> node->symbol.whatever
>> to
>> node->ref_symbol().whatever
>
> OK, the basic idea is that symtab_node is basetype of
> cgraph_node and varpool_node.
Yes.
> We may want to drop the historica cgraph/varpool names here,
> since function_node/variable_node would sound better. Cgraph
> still exists, but varpool is more or less historical relic.
I have a general preference for making name changes separate from
function changes when doing so makes svn diffs better reflect the
actual changes. That may or may not be useful here, but I am happy
to use those names for the final product.
> I would expect inheritance to allow me to write node->whatever
> and to have casting operators to convert things back and forth,
> so we only need to add testers?
The inheritance allows implicit derived to base conversion,
which is type-safe. With inheritance, the converting functions
are needed only for the conversion from base to derived, which
generally requires dynamic information to be safe.
> Probably is_function/is_variable & try_function/try_variable
> sounds more readable to me. What do you think?
Fine with me.
> (I just arrived from China, so will take it more tought once
> unjetlagged)
--
Lawrence Crowl
Re: Cgraph Modification Plan
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 about trying that myself. Did not know gengtype
> do not understand inheritance yet.
>>
>> APPROACH ###
>>
>> Add converters and testers.
>> Change callers to use those.
>> Change callers to use type-safe parameters.
>> Change implementation to class hierarchy.
>> Add accessors.
>
> Sounds good to me.
>>
>>
>> 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 &varpool_node::ref_symbol()
>> { return symbol; }
>>
>> change
>> node->symbol.whatever
>> to
>> node->ref_symbol().whatever
>
> 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 still exists, but
> varpool is more or less historical relic.
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
global variable table. The function table should replace the current
cgraph node link list, and the variable table replaces the varpool.
The symbol table should provide basic interfaces to do named based
lookup, traversal, alias handling etc. I noticed trunk already has
some of that -- but it seems more abstraction is needed.
3) it seems natural to drop 'node' in the naming scheme
symbol (symtab_entry) --> base class;
function --> derived from symbol; (It conflicts with the existing
struct function though);
variable --> derived from symbol;
typedef node cnode;
4) coding convention is needed for functions that do 'casting' and
'trial casting'.
thanks,
David
>
> I would expect inheritance to allow me to write node->whatever and to have
> casting operators to convert things back and forth, so we only need to add
> testers? Probably is_function/is_variable & try_function/try_variable sounds
> more readable to me.
> What do you think? (I just arrived from China, so will take it more tought
> once unjetlagged)
>
> Honza
>>
>>
>>
>> should not need to add these
>>
>> cgraph_node &symtab_node_def::ref_cgraph()
>> { gcc_assert (symbol.type == SYMTAB_FUNCTION);
>> return x_function; }
>> varpool_node &symtab_node_def::ref_varpool()
>> { gcc_assert (symbol.type == SYMTAB_VARIABLE);
>> return x_variable; }
>>
>>
>>
>> add
>> symtab_node_base *symtab_node_def::try_symbol()
>> { return &symbol; }
>> cgraph_node *symtab_node_def::try_cgraph()
>> { return symbol.type == SYMTAB_FUNCTION ? &x_function : NULL; }
>> varpool_node *symtab_node_def::try_varpool()
>> { return symbol.type == SYMTAB_VARIABLE ? &x_variable : NULL; }
>>
>> change
>> if (symtab_function_p (node) && cgraph (node)->analyzed)
>> return cgraph (node);
>> to
>> if (cgraph_node *p = node->try_cgraph())
>> if (p->analyzed)
>> return p;
>>
>> change
>> if (symtab_function_p (node) && cgraph (node)->callers)
>>
>> to
>> if (cgraph_node *p = node->try_cgraph())
>> if (p->callers)
>>
>>
>> change
>> if (symtab_function_p (node))
>> {
>> struct cgraph_node *cnode = cgraph (node);
>>
>> to
>> if (cgraph_node *cnode = node->try_cgraph ())
>> {
>>
>>
>>
>> likewise "symtab_variable_p (node)" and "varpool (node)"
>>
>>
>>
>> If there are any "symtab_function_p (node)" expressions left,
>>
>> add
>> bool symtab_node_def::is_cgraph()
>> { return symbol.type == SYMTAB_FUNCTION; }
>> bool symtab_node_def::is_varpool()
>> { return symbol.type == SYMTAB_VARIABLE; }
>>
>> change
>> symtab_function_p (node)
>> to
>> node->is_cgraph ()
>>
>> likewise "symtab_variable_p (node)"
>>
>>
>>
>>
>> Though we would like to avoid doing so,
>> if there are any "cgraph (node)" or "varpool (node)" expressions left,
>>
>> add
>>
>> symtab_node_base *symtab_node_def::ptr_symbol()
>> { return &symbol; }
>> cgraph_node *symtab_node_def::ptr_cgraph()
>> { gcc_assert (symbol.type == SYMTAB_FUNCTION);
>> { return &x_function; }
>> varpool_node *symtab_node_def::ptr_varpool()
>> { gcc_assert (symbol.type == SYMTAB_VARIABLE);
>> { return &x_variable; }
>>
>> change
>> cgraph (node) => node->ptr_cgraph()
>>
>> likewise "varpool (n
Re: Cgraph Modification Plan
> 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 understand inheritance yet.
>
> APPROACH ###
>
> Add converters and testers.
> Change callers to use those.
> Change callers to use type-safe parameters.
> Change implementation to class hierarchy.
> Add accessors.
Sounds good to me.
>
>
> 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 &varpool_node::ref_symbol()
> { return symbol; }
>
> change
> node->symbol.whatever
> to
> node->ref_symbol().whatever
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 still exists, but
varpool is more or less historical relic.
I would expect inheritance to allow me to write node->whatever and to have
casting operators to convert things back and forth, so we only need to add
testers? Probably is_function/is_variable & try_function/try_variable sounds
more readable to me.
What do you think? (I just arrived from China, so will take it more tought
once unjetlagged)
Honza
>
>
>
> should not need to add these
>
> cgraph_node &symtab_node_def::ref_cgraph()
> { gcc_assert (symbol.type == SYMTAB_FUNCTION);
> return x_function; }
> varpool_node &symtab_node_def::ref_varpool()
> { gcc_assert (symbol.type == SYMTAB_VARIABLE);
> return x_variable; }
>
>
>
> add
> symtab_node_base *symtab_node_def::try_symbol()
> { return &symbol; }
> cgraph_node *symtab_node_def::try_cgraph()
> { return symbol.type == SYMTAB_FUNCTION ? &x_function : NULL; }
> varpool_node *symtab_node_def::try_varpool()
> { return symbol.type == SYMTAB_VARIABLE ? &x_variable : NULL; }
>
> change
> if (symtab_function_p (node) && cgraph (node)->analyzed)
> return cgraph (node);
> to
> if (cgraph_node *p = node->try_cgraph())
> if (p->analyzed)
> return p;
>
> change
> if (symtab_function_p (node) && cgraph (node)->callers)
>
> to
> if (cgraph_node *p = node->try_cgraph())
> if (p->callers)
>
>
> change
> if (symtab_function_p (node))
> {
> struct cgraph_node *cnode = cgraph (node);
>
> to
> if (cgraph_node *cnode = node->try_cgraph ())
> {
>
>
>
> likewise "symtab_variable_p (node)" and "varpool (node)"
>
>
>
> If there are any "symtab_function_p (node)" expressions left,
>
> add
> bool symtab_node_def::is_cgraph()
> { return symbol.type == SYMTAB_FUNCTION; }
> bool symtab_node_def::is_varpool()
> { return symbol.type == SYMTAB_VARIABLE; }
>
> change
> symtab_function_p (node)
> to
> node->is_cgraph ()
>
> likewise "symtab_variable_p (node)"
>
>
>
>
> Though we would like to avoid doing so,
> if there are any "cgraph (node)" or "varpool (node)" expressions left,
>
> add
>
> symtab_node_base *symtab_node_def::ptr_symbol()
> { return &symbol; }
> cgraph_node *symtab_node_def::ptr_cgraph()
> { gcc_assert (symbol.type == SYMTAB_FUNCTION);
> { return &x_function; }
> varpool_node *symtab_node_def::ptr_varpool()
> { gcc_assert (symbol.type == SYMTAB_VARIABLE);
> { return &x_variable; }
>
> change
> cgraph (node) => node->ptr_cgraph()
>
> likewise "varpool (node)"
>
>
> TYPE SAFETY ###
>
> If a function asserts that its symtab_node parameter is symtab_function_p,
> then convert the function to take a cgraph_node*
> and change the callers to convert as above.
>
>
> PROPOSED HIERARCHY ###
>
> enum symtab_type { SYMTAB_SYMBOL, SYMTAB_FUNCTION, SYMTAB_VARIABLE };
>
> struct symtab_node_base /* marked SYMTAB_SYMBOL */
> embeds symtab_type
>
> cgraph_node : symtab_node_base /* marked SYMTAB_FUNCTION */
>
> varpool_node : symtab_node_base /* marked SYMTAB_VARIABLE */
>
> changing
> typedef union symtab_node_def *symtab_node;
> typedef const union symtab_node_def *const_symtab_node;
> to
> typedef symtab_node_base *symtab_node;
> typedef const symtab_node_base *const_symtab_node;
>
> changing used of
> symtab_node_def
> to
> symtab_node_base
>
> --
> Lawrence Crowl
Re: Merging Cilk Plus into GCC Trunk
On 09/05/12 12:09, Iyer, Balaji V wrote: I can't speak for the rest of the community, but I think items 1-12 are useful for GCC (elemental functions, SIMD annotations, and array notations for C/C++), regardless of any language extensions. Perhaps you could provide examples on these as a start? I was planning to provide an example for elemental function, array notations and SIMD annotations with each patch. Is that good enough? Yes. Regarding the SIMD annotations, I find the "vector" attribute somewhat ambiguous, or prone to confusing users, so perhaps we could come up with a better name? The keyword "vector" is used by the Intel Compiler and we would like them both to be compatible. Jakub at Cauldron did mention that vector keyword is used in Power PC and thus can potentially cause some interference. I configured the Cilk Plus branch for Power PC and I compiled both elemental functions and PowerPC programs that use the vector keyword. They both seem to work correctly. Ok, I'll defer to the language experts. Aldy
Re: Merging Cilk Plus into GCC Trunk
On 09/05/2012 12:59 PM, Joseph S. Myers wrote: Regarding the patch ordering you list, note that earlier patches may not be reviewable without later ones (specifically, code changes can only be reviewed given documentation and testcases - in some cases documentation might be external, but it does need to be pointed to from the GCC manuals in that case, and it does need to make interactions with existing language features precise at the level of standards text). Joseph, Just an FYI, I asked Balaji to do his best to break things down into more managable hunks of code to make review easier. In cases where we need a later patch (testcodes, docs, etc) we'll deal with the dependencies. WRT doc standards precision -- agreed. One of the major problems with the early language extensions was the lack of precision in their documentation. I don't think this is going to be a big problem for Cilk+, but only time will tell. Jeff
RE: Merging Cilk Plus into GCC Trunk
Hello Joseph, Please see my response below. Thanks, Balaji V. Iyer. >-Original Message- >From: Joseph Myers [mailto:jos...@codesourcery.com] >Sent: Wednesday, September 05, 2012 3:00 PM >To: Iyer, Balaji V >Cc: Aldy Hernandez; 'gcc@gcc.gnu.org'; Jeff Law; r...@redhat.com >Subject: RE: Merging Cilk Plus into GCC Trunk > >On Wed, 5 Sep 2012, Iyer, Balaji V wrote: > >> If this is OK with everyone, I will start sending patches to >> gcc-patches mailing list soon. > >Regarding the patch ordering you list, note that earlier patches may not be >reviewable without later ones (specifically, code changes can only be reviewed >given documentation and testcases - in some cases documentation might be >external, but it does need to be pointed to from the GCC manuals in that case, >and it does need to make interactions with existing language features precise >at >the level of standards text). I will try to send the test case patch and the code-changes patches back to back. Regarding documentation, I am planning to include a link to the documentation for Cilk Plus in the patches email. > >-- >Joseph S. Myers >jos...@codesourcery.com
Re: Telling plugins about build,host,target triplet strings
On Wed, 5 Sep 2012, Basile Starynkevitch wrote: > Well, to take a concrete example, I don't understand well how on > Debian/Sid can I know that the gcc-4.6-plugin-dev package is for > x86-64-unknown-linux. the files provided by that package don't tell > much. The plugin itself shouldn't need to know or care about that (remember, the same plugin, built for a different host but the same target, should behave identically). And to the extent the plugin cares about e.g. host C library features, I think the expectation would be to use autoconf to detect those. > Or are you suggesting I should use the packaging metainformation? I am suggesting that the logical concepts plugins should care about do not include the host triplet at all. (They might include "how do I execute compiled code", but I'd think that would best be externally configured in some way.) Whatever the problem is, I don't think using a host triplet in a plugin is the right solution. But you, as a human being, wanting to know the configuration of a particular distribution package, should indeed examine the metadata of that package (or of your installation as a whole). -- Joseph S. Myers jos...@codesourcery.com
RE: Merging Cilk Plus into GCC Trunk
On Wed, 5 Sep 2012, Iyer, Balaji V wrote: > If this is OK with everyone, I will start sending patches to > gcc-patches mailing list soon. Regarding the patch ordering you list, note that earlier patches may not be reviewable without later ones (specifically, code changes can only be reviewed given documentation and testcases - in some cases documentation might be external, but it does need to be pointed to from the GCC manuals in that case, and it does need to make interactions with existing language features precise at the level of standards text). -- Joseph S. Myers jos...@codesourcery.com
Cgraph Modification Plan
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, SYMTAB_FUNCTION, SYMTAB_VARIABLE };
struct symtab_node_base /* marked SYMTAB_SYMBOL */
embeds symtab_type
struct cgraph_node /* marked SYMTAB_FUNCTION */
embeds leading struct symtab_node_base symbol;
struct cgraph_local_info local;
struct cgraph_global_info global;
struct cgraph_rtl_info rtl;
struct cgraph_clone_info clone;
struct cgraph_thunk_info thunk;
typedef struct cgraph_node *cgraph_node_ptr;
struct varpool_node /* marked SYMTAB_VARIABLE */
embeds leading struct symtab_node_base symbol;
cgraph.h:typedef struct varpool_node *varpool_node_ptr;
union symtab_node_def
struct symtab_node_base GTY ((tag ("SYMTAB_SYMBOL"))) symbol;
struct cgraph_node GTY ((tag ("SYMTAB_FUNCTION"))) x_function;
struct varpool_node GTY ((tag ("SYMTAB_VARIABLE"))) x_variable;
typedef union symtab_node_def *symtab_node;
typedef const union symtab_node_def *const_symtab_node;
static inline struct cgraph_node *cgraph (symtab_node node);
static inline struct varpool_node *varpool (symtab_node node);
APPROACH ###
Add converters and testers.
Change callers to use those.
Change callers to use type-safe parameters.
Change implementation to class hierarchy.
Add accessors.
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 &varpool_node::ref_symbol()
{ return symbol; }
change
node->symbol.whatever
to
node->ref_symbol().whatever
should not need to add these
cgraph_node &symtab_node_def::ref_cgraph()
{ gcc_assert (symbol.type == SYMTAB_FUNCTION);
return x_function; }
varpool_node &symtab_node_def::ref_varpool()
{ gcc_assert (symbol.type == SYMTAB_VARIABLE);
return x_variable; }
add
symtab_node_base *symtab_node_def::try_symbol()
{ return &symbol; }
cgraph_node *symtab_node_def::try_cgraph()
{ return symbol.type == SYMTAB_FUNCTION ? &x_function : NULL; }
varpool_node *symtab_node_def::try_varpool()
{ return symbol.type == SYMTAB_VARIABLE ? &x_variable : NULL; }
change
if (symtab_function_p (node) && cgraph (node)->analyzed)
return cgraph (node);
to
if (cgraph_node *p = node->try_cgraph())
if (p->analyzed)
return p;
change
if (symtab_function_p (node) && cgraph (node)->callers)
to
if (cgraph_node *p = node->try_cgraph())
if (p->callers)
change
if (symtab_function_p (node))
{
struct cgraph_node *cnode = cgraph (node);
to
if (cgraph_node *cnode = node->try_cgraph ())
{
likewise "symtab_variable_p (node)" and "varpool (node)"
If there are any "symtab_function_p (node)" expressions left,
add
bool symtab_node_def::is_cgraph()
{ return symbol.type == SYMTAB_FUNCTION; }
bool symtab_node_def::is_varpool()
{ return symbol.type == SYMTAB_VARIABLE; }
change
symtab_function_p (node)
to
node->is_cgraph ()
likewise "symtab_variable_p (node)"
Though we would like to avoid doing so,
if there are any "cgraph (node)" or "varpool (node)" expressions left,
add
symtab_node_base *symtab_node_def::ptr_symbol()
{ return &symbol; }
cgraph_node *symtab_node_def::ptr_cgraph()
{ gcc_assert (symbol.type == SYMTAB_FUNCTION);
{ return &x_function; }
varpool_node *symtab_node_def::ptr_varpool()
{ gcc_assert (symbol.type == SYMTAB_VARIABLE);
{ return &x_variable; }
change
cgraph (node) => node->ptr_cgraph()
likewise "varpool (node)"
TYPE SAFETY ###
If a function asserts that its symtab_node parameter is symtab_function_p,
then convert the function to take a cgraph_node*
and change the callers to convert as above.
PROPOSED HIERARCHY ###
enum symtab_type { SYMTAB_SYMBOL, SYMTAB_FUNCTION, SYMTAB_VARIABLE };
struct symtab_node_base /* marked SYMTAB_SYMBOL */
embeds symtab_type
cgraph_node : symtab_node_base /* marked SYMTAB_FUNCTION */
varpool_node : symtab_node_base /* marked SYMTAB_VARIABLE */
changing
typedef union symtab_node_def *symtab_node;
typedef const union symtab_node_def *const_symtab_node;
to
typedef symtab_node_base *symtab_node;
typedef const symtab_node_base *const_symtab_node;
changing used of
symtab_node_def
to
symtab_node_base
--
Lawrence Crowl
Re: Telling plugins about build,host,target triplet strings
On Wed, Sep 05, 2012 at 03:14:40PM +, Joseph S. Myers wrote:
> On Wed, 5 Sep 2012, Basile Starynkevitch wrote:
>
> > const char* plugin_build_triplet (void);
>
> I think if you want to tell the plugin about the build triplet in this
> sort of way, there is some fundamental confusion involved. A compiler
> built for a given host and target pair should behave the same independent
> of what system it was built on (what the build triplet was) - and
> similarly, such a compiler could use plugins built on different systems
> from the build system on which the compiler itself was built (whereas all
> plugins would need to be configured for the same host and target as the
> compiler).
I agree that the build triplet is not important and could stay secret to
plugins.
However, we still need:
const char* plugin_host_triplet (void);
const char* plugin_target_triplet (void);
and I still have no clues of how to get that information
(so I am not yet able to submit a patch).
>
> The target triplet is proper information for a plugin to enquire about.
> The build triplet definitely is not. The host triplet probably isn't
> either (compilers for the same target, and different hosts, should also
> behave the same) although there may be some limited use cases where your
> plugin is explicitly not following the conventions of GCC proper regarding
> host-independence. Your use case for testing sounds like something where
> the build infrastructure for your plugin should be determining what to do
> depending on the triplets, rather than the plugin itself knowing about
> them.
Well, to take a concrete example, I don't understand well how on Debian/Sid can
I know that the
gcc-4.6-plugin-dev package is for x86-64-unknown-linux. the files provided by
that package don't tell much.
Or are you suggesting I should use the packaging metainformation?
Ian Taylor suggested in http://gcc.gnu.org/ml/gcc/2012-08/msg00339.html
to use CROSS_DIRECTORY_STRUCTURE but I can't find it there.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
RE: Merging Cilk Plus into GCC Trunk
Hello Aldy, Thank you for responding. Please see my answers to your questions embedded below. If this is OK with everyone, I will start sending patches to gcc-patches mailing list soon. Thanks, Balaji V. Iyer. >-Original Message- >From: Aldy Hernandez [mailto:al...@redhat.com] >Sent: Tuesday, September 04, 2012 6:24 PM >To: Iyer, Balaji V >Cc: 'gcc@gcc.gnu.org'; Jeff Law; r...@redhat.com >Subject: Re: Merging Cilk Plus into GCC Trunk > >On 08/30/12 15:39, Iyer, Balaji V wrote: >> Hello Everyone, >> The Cilk-Plus branch is feature-complete. Programs using Cilk Plus >constructs get great performance on vector and multicore hardware. Programs >that don't use the new language features (enabled by a -fcilkplus flag) see no >change. For details please see http://cilkplus.org. >> It's time to promote the branch into mainline. Cilk Plus branch is >> stable >and there is no unexpected failures with respect to the trunk in regression >testsuites. Most of the changes are in the front and middle-end. Since it >involves >many changes, I plan to break it up into individual patches (listed below), >each of >which adds a new, complete capability. Later patches sometimes use the >functionality added by the previous one. For example, Elemental functions for >C++ will depend on some of the common routines used in C patch: > >Hi Iyer. > >Thank you for all your work on this. > >Perhaps it is of interest to note (IIRC), that the language extensions have >been >proposed for inclusion in the next OpenMP version?? Cilk Plus has been proposed for inclusion in the next C++ standard. > >I can't speak for the rest of the community, but I think items 1-12 are useful >for >GCC (elemental functions, SIMD annotations, and array notations for C/C++), >regardless of any language extensions. Perhaps you could provide examples on >these as a start? > I was planning to provide an example for elemental function, array notations and SIMD annotations with each patch. Is that good enough? > >Regarding the SIMD annotations, I find the "vector" attribute somewhat >ambiguous, or prone to confusing users, so perhaps we could come up with a >better name? The keyword "vector" is used by the Intel Compiler and we would like them both to be compatible. Jakub at Cauldron did mention that vector keyword is used in Power PC and thus can potentially cause some interference. I configured the Cilk Plus branch for Power PC and I compiled both elemental functions and PowerPC programs that use the vector keyword. They both seem to work correctly. > >Over all, I don't see why this can't be included as an experimental feature >like >OpenMP, transactional memory, etc, especially if it's relatively self >contained and >doesn't affected the non cilkplus code path too much. > >Anyone have further thoughts on this, especially global maintainers :)? >Aldy > >> >> 1. Elemental functions for C. >> 2. Regression tests for elemental functions for C. >> 3. Elemental functions for C++. >> 4. Regression tests for elemental functions for C++. >> 5. SIMD annotations for C. >> 6. Regression tests for SIMD annotations for C. >> 7. SIMD annotations for C++. >> 8. Regression tests for SIMD annotations for C++. >> 9. Array notations for C. >> 10. Regression tests for Array notations for C. >> 11. Array Notations for C++. >> 12. Regression tests for Array Notations for C++. >> 13. The Cilk Runtime library -- It is a separate directory without any >> changes to >compiler source. >> 14. Cilk Keywords (_Cilk_spawn and _Cilk_sync) for C. >> 15. Regression tests _Cilk_spawn and _Cilk_sync for C. >> 16. Cilk Keywords (_Cilk_spawn and _Cilk_sync) for C++. >> 17. Regression tests _Cilk_spawn and _Cilk_sync for C++. >> 18. Cilk Keywords (_Cilk_for) for C. >> 19. _Cilk_for Regression tests for C. >> 20. Cilk Keywords (_Cilk_for) for C++. >> 21. _Cilk_for Regression tests for C++. >> 22. Documentation about Cilk Plus into GCC documents. >> >> If there is a more effective way to merge our changes to the trunk, I am open >to suggestions. >> >> Thanking You, >> >> Yours Sincerely, >> >> Balaji V. Iyer. >>
Re: Telling plugins about build,host,target triplet strings
On Wed, 5 Sep 2012, Basile Starynkevitch wrote: > const char* plugin_build_triplet (void); I think if you want to tell the plugin about the build triplet in this sort of way, there is some fundamental confusion involved. A compiler built for a given host and target pair should behave the same independent of what system it was built on (what the build triplet was) - and similarly, such a compiler could use plugins built on different systems from the build system on which the compiler itself was built (whereas all plugins would need to be configured for the same host and target as the compiler). The target triplet is proper information for a plugin to enquire about. The build triplet definitely is not. The host triplet probably isn't either (compilers for the same target, and different hosts, should also behave the same) although there may be some limited use cases where your plugin is explicitly not following the conventions of GCC proper regarding host-independence. Your use case for testing sounds like something where the build infrastructure for your plugin should be determining what to do depending on the triplets, rather than the plugin itself knowing about them. -- Joseph S. Myers jos...@codesourcery.com
Telling plugins about build,host,target triplet strings
Hello All,
In http://gcc.gnu.org/ml/gcc/2012-08/msg00339.html Ian Taylor wrote:
> In general I would support having ways for plugins to detect this sort
> of thing, perhaps simply by making the build, host, and target triplet
> strings available to the plugin in some way.
I would like to get that in 4.8, but I have no idea of how to do it.
Do you have any hints about that? I was thinking of adding perhaps in
plugin.[ch] functions like
// Give triplet like x86_64-linux-gnu for the build, host and target systems
const char* plugin_build_triplet (void);
const char* plugin_host_triplet (void);
const char* plugin_target_triplet (void);
I was naively hoping the "x86_64-linux-gnu" string to appear in some generated
"source"
[I mean, outside of *.o object files] file or header in the build tree,
but it does not seem to be that simple...
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
