Re: [PATCH 0/3] Compile-time gimple checking, without typedefs
On 05/02/14 15:56, David Malcolm wrote: This patch series demonstrates a way of reimplementing the 89-patch series: [PATCH 00/89] Compile-time gimple-checking http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01148.html whilst avoiding introducing a pair of gimple_foo/const_gimple_foo typedefs for each subclass. It eliminates the gimple and const_gimple typedefs, renaming gimple_statement_base to gimple_stmt, giving types: gimple_stmt * and const gimple_stmt * thoughout the middle-end. The rest of the gimple statement classes are renamed, converting the various gimple_statement_with_FOO to: gimple_stmt_with_FOO and the remainder: gimple_statement_SOME_SUBCLASS to just: gimple_SOME_SUBCLASS The idea is then to reimplement the earlier patch series, porting many of these: gimple_stmt *something to point to some more concrete subclass; I've done this for GIMPLE_SWITCH. It requires two patches that I've already posted separately: (A): [PATCH] gengtype: Support explicit pointers in template arguments: http://gcc.gnu.org/ml/gcc-patches/2014-05/msg3.html (which apparently will need reworking after wide-int is merged; oh well). So, wide-int has been merged, so time to get this patch dealt with. As mentioned before, if it's just trivial changes, consider it pre-approved. Else please get another review. Obviously in both cases it needs to be posted to gcc-patches. (B): [PATCH 19/89] Const-correctness of gimple_call_builtin_p: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01194.html (I have a separate bootstrapregrtest in progress for just this one, which appears to be pre-approved per Jeff's earlier comments). Yes, this would meet the pre-approval criteria. Just to be explicit, I approved it tonight anyway :-) So it looks like Richi really wanted to keep the statements as gimple rather than gimple_stmt or somesuch. So that presumably requires some reworking this patch series, but those should be strictly name changes, right? jeff
Re: [PATCH 0/3] Compile-time gimple checking, without typedefs
On Mon, May 05, 2014 at 09:53:49PM +0200, Jakub Jelinek wrote: On Mon, May 05, 2014 at 01:44:06PM -0600, Jeff Law wrote: On 05/05/14 11:37, Richard Biener wrote: Well, I hope that Andrew doesn't do without a namespace (and I still don't believe in what he tries to achieve without laying proper ground-work throughout the compiler). With a namespace gimple we can use gimple::stmt. namespaces, while nice, aren't going to solve all these issues. While I think we can get a good separation between gimple and the rest of the world, I suspect namespaces aren't going to help much with the statement vs expression vs type issues. Ultimately I suspect we're not going to have too many places where we can stick a using namespace gimple-whatever, but time will tell. Agreed on that, btw. But switch_ can't be the answer either. Maybe swidch (similar do klass) or swjdch. Or swtch. I like swtch the best (similar to stmt). As David pointed out there's several others that map to keywords. I'd rather set a standard here across the project so that we don't have folks using gto for goto, others using goto_, _goto, whatever. While swtch works well, I don't think the other examples work nearly as well. Thus some kind of prefix/suffix seems better to me (though I'm sure my eyes will bleed as a result of looking at those objects). But the prefix can be as short as e.g. g (for gimple), so gtry, ggoto, gassign, gcall. Jakub My thoughts exactly. (And I'd also leave the general statement type called gimple.) Martin
Re: [PATCH 0/3] Compile-time gimple checking, without typedefs
On Mon, 2014-05-05 at 21:53 +0200, Jakub Jelinek wrote: On Mon, May 05, 2014 at 01:44:06PM -0600, Jeff Law wrote: On 05/05/14 11:37, Richard Biener wrote: Well, I hope that Andrew doesn't do without a namespace (and I still don't believe in what he tries to achieve without laying proper ground-work throughout the compiler). With a namespace gimple we can use gimple::stmt. namespaces, while nice, aren't going to solve all these issues. While I think we can get a good separation between gimple and the rest of the world, I suspect namespaces aren't going to help much with the statement vs expression vs type issues. Ultimately I suspect we're not going to have too many places where we can stick a using namespace gimple-whatever, but time will tell. Agreed on that, btw. But switch_ can't be the answer either. Maybe swidch (similar do klass) or swjdch. Or swtch. I like swtch the best (similar to stmt). As David pointed out there's several others that map to keywords. I'd rather set a standard here across the project so that we don't have folks using gto for goto, others using goto_, _goto, whatever. While swtch works well, I don't think the other examples work nearly as well. Thus some kind of prefix/suffix seems better to me (though I'm sure my eyes will bleed as a result of looking at those objects). But the prefix can be as short as e.g. g (for gimple), so gtry, ggoto, gassign, gcall. FWIW, I like this: I think it's clear and concise, and I think it avoids the need for namespaces. (I'd prefer not to have a namespace, due to gengtype). Given Richi's preference for the base class being gimple, that could give: Existing New --- gimple gimple * gimple gswitch * a GIMPLE_SWITCH gimple gcall * a GIMPLE_CALL etc with the various gimple_statement_with_FOO becoming just gimple_with_FOO e.g. gimple_with_memory_ops How would you want subclasses for the OpenMP statements to be named? e.g. replace gimple_statement_omp with gomp_ for e.g. gomp_for * or to gimple_omp_, giving e.g. gimple_omp_for * with the former (less verbose) approach giving the following names, I think (showing the class hierarchy): gimple |layout: GSS_BASE |used for 4 codes: GIMPLE_ERROR_MARK | GIMPLE_NOP | GIMPLE_OMP_SECTIONS_SWITCH | GIMPLE_PREDICT | + gimple_with_ops_base | |(no GSS layout) | | | + gimple_with_ops | | |layout: GSS_WITH_OPS | | | | | + gcond | | | code: GIMPLE_COND | | | | | + gdebug | | | code: GIMPLE_DEBUG | | | | | + ggoto | | | code: GIMPLE_GOTO | | | | | + glabel | | | code: GIMPLE_LABEL | | | | | + gswitch | | code: GIMPLE_SWITCH | | | + gimple_with_memory_ops_base | |layout: GSS_WITH_MEM_OPS_BASE | | | + gimple_with_memory_ops | | |layout: GSS_WITH_MEM_OPS | | | | | + gassign | | |code GIMPLE_ASSIGN | | | | | + greturn | |code GIMPLE_RETURN | | | + gcall | |layout: GSS_CALL, code: GIMPLE_CALL | | | + gasm | |layout: GSS_ASM, code: GIMPLE_ASM | | | + gtransaction |layout: GSS_TRANSACTION, code: GIMPLE_TRANSACTION | + gomp | |layout: GSS_OMP. Used for code GIMPLE_OMP_SECTION | | | + gomp_critical | |layout: GSS_OMP_CRITICAL, code: GIMPLE_OMP_CRITICAL | | | + gomp_for | |layout: GSS_OMP_FOR, code: GIMPLE_OMP_FOR | | | + gomp_parallel_layout | | |layout: GSS_OMP_PARALLEL_LAYOUT | | | | | + gomp_taskreg | | | | | | | + gomp_parallel | | | |code: GIMPLE_OMP_PARALLEL | | | | | | | + gomp_task | | |code: GIMPLE_OMP_TASK | | | | | + gomp_target | |code: GIMPLE_OMP_TARGET | | | + gomp_sections | |layout: GSS_OMP_SECTIONS, code: GIMPLE_OMP_SECTIONS | | | + gomp_single_layout | |layout: GSS_OMP_SINGLE_LAYOUT | | | + gomp_single | |code: GIMPLE_OMP_SINGLE | | | + gomp_teams |code: GIMPLE_OMP_TEAMS | + gbind |layout: GSS_BIND, code: GIMPLE_BIND | + gcatch |layout: GSS_CATCH, code: GIMPLE_CATCH | + geh_filter |layout: GSS_EH_FILTER, code: GIMPLE_EH_FILTER | +
Re: [PATCH 0/3] Compile-time gimple checking, without typedefs
On 05/06/14 12:58, David Malcolm wrote: But the prefix can be as short as e.g. g (for gimple), so gtry, ggoto, gassign, gcall. FWIW, I like this: I think it's clear and concise, and I think it avoids the need for namespaces. (I'd prefer not to have a namespace, due to gengtype). Then let's go with it. gfoo is as reasonable as anything else we're likely to come up with. jeff
Re: [PATCH 0/3] Compile-time gimple checking, without typedefs
On May 6, 2014 9:15:09 PM CEST, Jeff Law l...@redhat.com wrote: On 05/06/14 12:58, David Malcolm wrote: But the prefix can be as short as e.g. g (for gimple), so gtry, ggoto, gassign, gcall. FWIW, I like this: I think it's clear and concise, and I think it avoids the need for namespaces. (I'd prefer not to have a namespace, due to gengtype). Then let's go with it. gfoo is as reasonable as anything else we're likely to come up with. Agreed. Richard. jeff
Re: [PATCH 0/3] Compile-time gimple checking, without typedefs
On Fri, May 2, 2014 at 11:56 PM, David Malcolm dmalc...@redhat.com wrote:
This patch series demonstrates a way of reimplementing the 89-patch series:
[PATCH 00/89] Compile-time gimple-checking
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01148.html
whilst avoiding introducing a pair of gimple_foo/const_gimple_foo typedefs
for each subclass.
It eliminates the gimple and const_gimple typedefs,
renaming gimple_statement_base to gimple_stmt, giving types:
gimple_stmt * and const gimple_stmt *
thoughout the middle-end. The rest of the gimple statement classes are
renamed, converting the various
gimple_statement_with_FOO
to:
gimple_stmt_with_FOO
and the remainder:
gimple_statement_SOME_SUBCLASS
to just:
gimple_SOME_SUBCLASS
The idea is then to reimplement the earlier patch series, porting many of
these:
gimple_stmt *something
to point to some more concrete subclass; I've done this for GIMPLE_SWITCH.
Thanks for doing this.
It requires two patches that I've already posted separately:
(A): [PATCH] gengtype: Support explicit pointers in template arguments:
http://gcc.gnu.org/ml/gcc-patches/2014-05/msg3.html
(which apparently will need reworking after wide-int is merged;
oh well).
I'll look at this after the wide-int merge (which hopefully happens soon...)
(B): [PATCH 19/89] Const-correctness of gimple_call_builtin_p:
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01194.html
(I have a separate bootstrapregrtest in progress for just this one,
which appears to be pre-approved per Jeff's earlier comments).
Of the 3 patches in the series itself:
Patch 1:
This one is handwritten: it renames the gimple statement classes in
their declarations, in the docs, in the selftests and renames explicit
uses of *subclasses*.
Patch 2:
This one is autogenerated: it does the mass conversion of gimple to
gimple_stmt * and const_gimple to const gimple_stmt * throughout
the code.
The conversion script is at:
https://github.com/davidmalcolm/gcc-refactoring-scripts/blob/master/rename_gimple.py
It's not a real C++ parser, but it has some smarts for handling
awkward cases like:
gimple def0, def2;
which must become:
gimple_stmt *def0, *def2;
^ note the second '*' character.
You can see the selftests for the conversion script at:
https://github.com/davidmalcolm/gcc-refactoring-scripts/blob/master/test_rename_gimple.py
Patch 3:
This one is a port of the previously-posted:
[PATCH 02/89] Introduce gimple_switch and use it in various places
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01154.html
to the new approach. As per an earlier revision:
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01549.html
it *eliminates* the
stmt-as_a_gimple_switch ()
and
stmt-dyn_cast_gimple_switch ()
casting methods from the base class in favor of direct usage of is-a.h:
as_a gimple_switch * (stmt)
and
dyn_cast gimple_switch * (stmt)
This version of the patch also eliminates the
gimple_switch / const_gimple_switch
typedefs from the initial patch series in favor of gimple_switch
being the name of the subclass.
I wonder if, when we intoduce a gimple namespace, we can write
dyn_cast switch * (stmt)
by means of ADL? Thus, imagine just doing
namespace gimple {
... gimple.h contents ...
}
using gimple::gimple;
... a few more? ...
typedef gimple::gimple gimple;
And then
gimple *stmt;
gimple::switch *s = dyn_cast switch * (stmt);
(yeah, awkward 'switch' reserved keyword as you say below ...)
Thus, for all the new explicit sub-types you introduce use the namespace
syntax. Can ADL work in our favors here with the way dyn_cast and
friends work? Thus, do we really need to write dyn_cast
gimple::switch * (stmt)?
No, I'm not asking you to do that now (but a limited form of a gimple namespace
would be nice to have - using the old-style 'gimple' type avoids changing too
much code I suppose).
Just sth that you don't run out of work ;)
Hopefully porting this first patch in the series gives a sense of what
the end-result would look like.
There are a few possible variations on the names we could pick in this
approach.
I deliberately renamed gimple to gimple_stmt since IIRC Andrew MacLeod
had suggested something like this, for the potential of making gimple
be a namespace. That said, using namespaces may be controversial, and
would need further gengtype support, which may be tricky (i.e. fully teach
gengtype about C++ namespaces, which may be a gengtype hack too far).
[I'd much prefer to avoid C++ namespaces in the core code, mostly because
of gengtype].
Also, AIUI, Andrew is looking at introducing concepts of gimple types and
gimple expressions, so gimple may no longer imply a *statement*.
Re: [PATCH 0/3] Compile-time gimple checking, without typedefs
On 05/05/14 02:22, Richard Biener wrote: Also, AIUI, Andrew is looking at introducing concepts of gimple types and gimple expressions, so gimple may no longer imply a *statement*. Alternatively, we could make the base class be just gimple (which would be more consistent with the names of the accessor functions). I strongly prefer to name it 'gimple', not 'gimple_stmt'. Because it's less to type, and because it will make all other types shorter as well. And because 'gimple' _is_ a stmt right now, so gimple_stmt is redundant. Same applies to gimple_stmt_with_FOO, just make it gimple_with_FOO. I understand the namespace issue, but we don't have a namespace right now. Also gimple::gimple works just fine, no? But this approach is going to be inconsistent with Andrew's work, right? ISTM we'd end up with something like... So statements would be gimple types would be gimple_type expressions would be gimple_expr It's a bit of bikeshedding, but I'd prefer gimple_stmt. If you really feel strongly about it, I'll go along without objection, but it seems wrong to me. There's also the bargain basement namespaces approach, where we don't have an implicit gimple namespace, but just *pretend* we do, and rename the base type to stmt, with e.g. gimple_statement_phi becoming just phi. [gimple_switch would need to become switch_, say, to avoid the reserved word]. Ick (for the 'switch' case ... CamelCase anyone? :)). :-) Please, no Jeff
Re: [PATCH 0/3] Compile-time gimple checking, without typedefs
On Mon, May 5, 2014 at 6:01 PM, Jeff Law l...@redhat.com wrote: On 05/05/14 02:22, Richard Biener wrote: Also, AIUI, Andrew is looking at introducing concepts of gimple types and gimple expressions, so gimple may no longer imply a *statement*. Alternatively, we could make the base class be just gimple (which would be more consistent with the names of the accessor functions). I strongly prefer to name it 'gimple', not 'gimple_stmt'. Because it's less to type, and because it will make all other types shorter as well. And because 'gimple' _is_ a stmt right now, so gimple_stmt is redundant. Same applies to gimple_stmt_with_FOO, just make it gimple_with_FOO. I understand the namespace issue, but we don't have a namespace right now. Also gimple::gimple works just fine, no? But this approach is going to be inconsistent with Andrew's work, right? ISTM we'd end up with something like... So statements would be gimple types would be gimple_type expressions would be gimple_expr Well, I hope that Andrew doesn't do without a namespace (and I still don't believe in what he tries to achieve without laying proper ground-work throughout the compiler). With a namespace gimple we can use gimple::stmt. It's a bit of bikeshedding, but I'd prefer gimple_stmt. If you really feel strongly about it, I'll go along without objection, but it seems wrong to me. Less typing. But yes, it's bikeshedding. Still gimple_stmt is redundant information in almost all context. 'stmt' was opposed to elsewhere so we settle on 'gimple' (which is already existing). IMHO not changing things is the best bikeshedding argument. There's also the bargain basement namespaces approach, where we don't have an implicit gimple namespace, but just *pretend* we do, and rename the base type to stmt, with e.g. gimple_statement_phi becoming just phi. [gimple_switch would need to become switch_, say, to avoid the reserved word]. Ick (for the 'switch' case ... CamelCase anyone? :)). :-) Please, no Agreed on that, btw. But switch_ can't be the answer either. Maybe swidch (similar do klass) or swjdch. Or swtch. I like swtch the best (similar to stmt). Richard. Jeff
Re: [PATCH 0/3] Compile-time gimple checking, without typedefs
On Mon, 2014-05-05 at 19:37 +0200, Richard Biener wrote: On Mon, May 5, 2014 at 6:01 PM, Jeff Law l...@redhat.com wrote: On 05/05/14 02:22, Richard Biener wrote: Also, AIUI, Andrew is looking at introducing concepts of gimple types and gimple expressions, so gimple may no longer imply a *statement*. Alternatively, we could make the base class be just gimple (which would be more consistent with the names of the accessor functions). I strongly prefer to name it 'gimple', not 'gimple_stmt'. Because it's less to type, and because it will make all other types shorter as well. And because 'gimple' _is_ a stmt right now, so gimple_stmt is redundant. Same applies to gimple_stmt_with_FOO, just make it gimple_with_FOO. I understand the namespace issue, but we don't have a namespace right now. Also gimple::gimple works just fine, no? But this approach is going to be inconsistent with Andrew's work, right? ISTM we'd end up with something like... So statements would be gimple types would be gimple_type expressions would be gimple_expr Well, I hope that Andrew doesn't do without a namespace (and I still don't believe in what he tries to achieve without laying proper ground-work throughout the compiler). With a namespace gimple we can use gimple::stmt. It's a bit of bikeshedding, but I'd prefer gimple_stmt. If you really feel strongly about it, I'll go along without objection, but it seems wrong to me. Less typing. But yes, it's bikeshedding. Still gimple_stmt is redundant information in almost all context. 'stmt' was opposed to elsewhere so we settle on 'gimple' (which is already existing). IMHO not changing things is the best bikeshedding argument. There's also the bargain basement namespaces approach, where we don't have an implicit gimple namespace, but just *pretend* we do, and rename the base type to stmt, with e.g. gimple_statement_phi becoming just phi. [gimple_switch would need to become switch_, say, to avoid the reserved word]. Ick (for the 'switch' case ... CamelCase anyone? :)). :-) Please, no Agreed on that, btw. But switch_ can't be the answer either. Maybe swidch (similar do klass) or swjdch. Or swtch. I like swtch the best (similar to stmt). FWIW I assumed the ick from Jeff was in relation to CamelCase. Note that it's not just GIMPLE_SWITCH that has this problem when using this naming convention; I believe the list of codes that would have class names clashing with C++ keywords would be: GIMPLE_GOTO GIMPLE_SWITCH GIMPLE_RETURN GIMPLE_CATCH GIMPLE_TRY IMHO, I think trying to eliminate vowels or similar would be confusing (e.g. how does one respell try? [1]) and that standardizing on a trailing underscore for all of these seems to me to be cleaner and simpler. But, yeah, we're in bikeshedding territory here :) Dave [1] e.g. in patch 32 of the series which converts a dozen or so gimple vars in tree-eh.c to be explicitly one of these. trie would make me think of a data structure, rather than a try statement, and, errr trigh would make me think of Battlestar Galactica's XO :)
Re: [PATCH 0/3] Compile-time gimple checking, without typedefs
On 05/05/14 12:37, David Malcolm wrote: FWIW I assumed the ick from Jeff was in relation to CamelCase. Yes. That is a personal preference, of course. Note that it's not just GIMPLE_SWITCH that has this problem when using this naming convention; I believe the list of codes that would have class names clashing with C++ keywords would be: GIMPLE_GOTO GIMPLE_SWITCH GIMPLE_RETURN GIMPLE_CATCH GIMPLE_TRY IMHO, I think trying to eliminate vowels or similar would be confusing (e.g. how does one respell try? [1]) and that standardizing on a trailing underscore for all of these seems to me to be cleaner and simpler. Seems reasonable to me (trailing underscore). Or we could keep the gimple_ prefix. Jeff
Re: [PATCH 0/3] Compile-time gimple checking, without typedefs
On 05/05/14 11:37, Richard Biener wrote: Well, I hope that Andrew doesn't do without a namespace (and I still don't believe in what he tries to achieve without laying proper ground-work throughout the compiler). With a namespace gimple we can use gimple::stmt. namespaces, while nice, aren't going to solve all these issues. While I think we can get a good separation between gimple and the rest of the world, I suspect namespaces aren't going to help much with the statement vs expression vs type issues. Ultimately I suspect we're not going to have too many places where we can stick a using namespace gimple-whatever, but time will tell. Agreed on that, btw. But switch_ can't be the answer either. Maybe swidch (similar do klass) or swjdch. Or swtch. I like swtch the best (similar to stmt). As David pointed out there's several others that map to keywords. I'd rather set a standard here across the project so that we don't have folks using gto for goto, others using goto_, _goto, whatever. While swtch works well, I don't think the other examples work nearly as well. Thus some kind of prefix/suffix seems better to me (though I'm sure my eyes will bleed as a result of looking at those objects). jeff
Re: [PATCH 0/3] Compile-time gimple checking, without typedefs
On Mon, May 05, 2014 at 01:44:06PM -0600, Jeff Law wrote: On 05/05/14 11:37, Richard Biener wrote: Well, I hope that Andrew doesn't do without a namespace (and I still don't believe in what he tries to achieve without laying proper ground-work throughout the compiler). With a namespace gimple we can use gimple::stmt. namespaces, while nice, aren't going to solve all these issues. While I think we can get a good separation between gimple and the rest of the world, I suspect namespaces aren't going to help much with the statement vs expression vs type issues. Ultimately I suspect we're not going to have too many places where we can stick a using namespace gimple-whatever, but time will tell. Agreed on that, btw. But switch_ can't be the answer either. Maybe swidch (similar do klass) or swjdch. Or swtch. I like swtch the best (similar to stmt). As David pointed out there's several others that map to keywords. I'd rather set a standard here across the project so that we don't have folks using gto for goto, others using goto_, _goto, whatever. While swtch works well, I don't think the other examples work nearly as well. Thus some kind of prefix/suffix seems better to me (though I'm sure my eyes will bleed as a result of looking at those objects). But the prefix can be as short as e.g. g (for gimple), so gtry, ggoto, gassign, gcall. Jakub
Re: [PATCH 0/3] Compile-time gimple checking, without typedefs
On Mon, May 05, 2014 at 01:44:06PM -0600, Jeff Law wrote: On 05/05/14 11:37, Richard Biener wrote: Well, I hope that Andrew doesn't do without a namespace (and I still don't believe in what he tries to achieve without laying proper ground-work throughout the compiler). With a namespace gimple we can use gimple::stmt. namespaces, while nice, aren't going to solve all these issues. While I think we can get a good separation between gimple and the rest of the world, I suspect namespaces aren't going to help much with the statement vs expression vs type issues. Ultimately I suspect we're not going to have too many places where we can stick a using namespace gimple-whatever, but time will tell. yeah, gcc::gimple::stmt::switch seems a bit excessive ;) Agreed on that, btw. But switch_ can't be the answer either. Maybe swidch (similar do klass) or swjdch. Or swtch. I like swtch the best (similar to stmt). As David pointed out there's several others that map to keywords. I'd rather set a standard here across the project so that we don't have folks using gto for goto, others using goto_, _goto, whatever. While swtch works well, I don't think the other examples work nearly as well. Thus some kind of prefix/suffix seems better to me (though I'm sure my eyes will bleed as a result of looking at those objects). personally I've become desensitized to cammel case, but how about switch_stmt, goto_stmt etc? imho its not that bad to be a little explicit these are statement types, but yet its pretty short. Trev jeff signature.asc Description: Digital signature
[PATCH 0/3] Compile-time gimple checking, without typedefs
This patch series demonstrates a way of reimplementing the 89-patch series: [PATCH 00/89] Compile-time gimple-checking http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01148.html whilst avoiding introducing a pair of gimple_foo/const_gimple_foo typedefs for each subclass. It eliminates the gimple and const_gimple typedefs, renaming gimple_statement_base to gimple_stmt, giving types: gimple_stmt * and const gimple_stmt * thoughout the middle-end. The rest of the gimple statement classes are renamed, converting the various gimple_statement_with_FOO to: gimple_stmt_with_FOO and the remainder: gimple_statement_SOME_SUBCLASS to just: gimple_SOME_SUBCLASS The idea is then to reimplement the earlier patch series, porting many of these: gimple_stmt *something to point to some more concrete subclass; I've done this for GIMPLE_SWITCH. It requires two patches that I've already posted separately: (A): [PATCH] gengtype: Support explicit pointers in template arguments: http://gcc.gnu.org/ml/gcc-patches/2014-05/msg3.html (which apparently will need reworking after wide-int is merged; oh well). (B): [PATCH 19/89] Const-correctness of gimple_call_builtin_p: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01194.html (I have a separate bootstrapregrtest in progress for just this one, which appears to be pre-approved per Jeff's earlier comments). Of the 3 patches in the series itself: Patch 1: This one is handwritten: it renames the gimple statement classes in their declarations, in the docs, in the selftests and renames explicit uses of *subclasses*. Patch 2: This one is autogenerated: it does the mass conversion of gimple to gimple_stmt * and const_gimple to const gimple_stmt * throughout the code. The conversion script is at: https://github.com/davidmalcolm/gcc-refactoring-scripts/blob/master/rename_gimple.py It's not a real C++ parser, but it has some smarts for handling awkward cases like: gimple def0, def2; which must become: gimple_stmt *def0, *def2; ^ note the second '*' character. You can see the selftests for the conversion script at: https://github.com/davidmalcolm/gcc-refactoring-scripts/blob/master/test_rename_gimple.py Patch 3: This one is a port of the previously-posted: [PATCH 02/89] Introduce gimple_switch and use it in various places http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01154.html to the new approach. As per an earlier revision: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01549.html it *eliminates* the stmt-as_a_gimple_switch () and stmt-dyn_cast_gimple_switch () casting methods from the base class in favor of direct usage of is-a.h: as_a gimple_switch * (stmt) and dyn_cast gimple_switch * (stmt) This version of the patch also eliminates the gimple_switch / const_gimple_switch typedefs from the initial patch series in favor of gimple_switch being the name of the subclass. Hopefully porting this first patch in the series gives a sense of what the end-result would look like. There are a few possible variations on the names we could pick in this approach. I deliberately renamed gimple to gimple_stmt since IIRC Andrew MacLeod had suggested something like this, for the potential of making gimple be a namespace. That said, using namespaces may be controversial, and would need further gengtype support, which may be tricky (i.e. fully teach gengtype about C++ namespaces, which may be a gengtype hack too far). [I'd much prefer to avoid C++ namespaces in the core code, mostly because of gengtype]. Also, AIUI, Andrew is looking at introducing concepts of gimple types and gimple expressions, so gimple may no longer imply a *statement*. Alternatively, we could make the base class be just gimple (which would be more consistent with the names of the accessor functions). There's also the bargain basement namespaces approach, where we don't have an implicit gimple namespace, but just *pretend* we do, and rename the base type to stmt, with e.g. gimple_statement_phi becoming just phi. [gimple_switch would need to become switch_, say, to avoid the reserved word]. Successfully bootstrapped and regrtested on x86_64-unknown-linux-gnu (Fedora 20) (on top of the 2 dependent patches mentioned above; equal results compared to a control build of r209953. How does this look? (for trunk; after 4.9.1 is released). David Malcolm (3): Handwritten part of conversion of gimple to gimple_stmt * Autogenerated part of conversion of gimple to gimple_stmt * Introduce gimple_switch and use it in various places gcc/asan.c | 36 +- gcc/builtins.c | 10 +- gcc/builtins.h |2 +- gcc/c-family/c-gimplify.c|4 +- gcc/calls.c
