This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[gimple-classes] New branch (was Re: [RFC] Compile-time gimple-checking (again))

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:
> >>
> >> (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
this work.

It can be seen at:;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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]