This is the mail archive of the
mailing list for the GCC project.
[gimple-classes] New branch (was Re: [RFC] Compile-time gimple-checking (again))
- From: David Malcolm <dmalcolm at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 27 Oct 2014 15:59:29 -0400
- Subject: [gimple-classes] New branch (was Re: [RFC] Compile-time gimple-checking (again))
- Authentication-results: sourceware.org; auth=none
- References: <1413389724 dot 9513 dot 103 dot camel at surprise> <CAFiYyc3j=_gUrLdn8wx-gS_Zx62g4ZbG0=KROLgdmo4wphy2Tw at mail dot gmail dot com> <5440104A dot 1060901 at redhat dot com>
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
> >> 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.
I've created a new branch within git: "dmalcolm/gimple-classes" to track
It can be seen at:
(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.