On Thu, 2014-10-16 at 12:36 -0600, Jeff Law wrote: > 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.
Thanks. I've created a new branch within git: "dmalcolm/gimple-classes" to track this work. It can be seen at: https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/dmalcolm/gimple-classes (branching from r216157 aka fc222f445c6108418196a1b48703d350f3c3d45a) I've pushed 92 patches there so far, which I'm about to post to this list, with the prefix "[gimple-classes]". I'm accumulating the ChangeLogs into a gcc/ChangeLog.gimple-classes file, as well as in the commit messages. Dave
