On 10/16/14 05:27, Richard Biener wrote:
This required numerous essentially mechanical changes to the patches
e.g. for the big reworking of cgraph functions to be methods. I've been
working on the assumption that these various changes aren't going to
require a re-review.
If they're fairly mechanical, then I think we're OK.
I also removed the unloved as_a/dyn_cast methods from the gimple base
class in favor of as_a<>/dyn_cast<> functions from is-a.h
OK.
Are people still happy with the proposed naming from:
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00346.html
(incorporating the "pointerness" change of gimple to require "gimple
*").
How should I proceed? The proposal is going to require one or more
auto-generated "megapatches", and such a patch is going to bitrot
immediately... and break everyone else's patches and branches that touch
the middle-end if/when it goes in (the "gimple" to "gimple *" change is
the issue here).
I'm thinking that I could attempt to put all of the handwritten stuff
onto a (git) branch, or possibly put the .patch files though a renaming
script to partially automated things first e.g. by updating the patches
to use explicit pointers for *subclasses* as the patchkit introduces
uses of subclasses.
Then the big "gimple" to "gimple *" conversion could be done mostly
separately, once the rest of the branch was ready to go in. That would
allow trunk to be easily mergable *into* the branch for all except the
final autogenerated change. We'd avoid introducing lots of "const_"
typedefs, the only weird thing would be (until the final patch goes in)
having "gimple" implicitly be a ptr, whereas the subclasses would
require explicit ptr syntax.
A merging strategy could be:
- keep the branch hand-written, with ChangeLog.gimple-classes files
- develop on branch, fixing more accessors, posting to gcc-patches
- merge from trunk to the branch periodically
- when ready, merge from branch to trunk in one commit
- apply the final autogenerated change of "gimple" to "gimple *" in one
commit to trunk.
That way everything is diffable, and the awkward autogenerated megapatch
is isolated as one change.
Thoughts?
Overall I'm fine with both conversions and any order they happen in
given both happen (I'm also fine to only do gimple -> gimple * for this
stage1). I think timing-wise you should now have the burden to wait
for the end of stage1 (and thus all pending big merges). I'm fine doing
this refactoring very early in stage3. How you develop the patch is
left to you - I don't have strong opinions here.
No strong opinions here other than I think this stuff should go forward
during this stage1/early stage3. David delayed the work until after
4.9.1 was released and is doing a massive renaming -- we shouldn't
penalize him for meeting our requests. So as long as we're in agreement
this stuff is suitable now or early in stage3, then I'm comfortable with
either approach.
Jeff
