[PATCH 1/2] add staticly checked label_nuses accessors
Thu Sep 11 21:12:00 GMT 2014
On Thu, Sep 11, 2014 at 02:55:43PM -0600, Jeff Law wrote:
> On 09/05/14 16:38, Trevor Saunders wrote:
> >So, in this case it seems to me you basically have two options
> >A. change the macro to an inline function, and fix up all the callers to
> >pass the right type. Then rebase that into some sort of reasonable
> >patch series.
> >b. add a function with a different name and convert users piece meal,
> >and then remove the old macro (I guess you can then rename the new
> >function to the old macro if you like).
> >of those I prefer b because it means you can convert call sites one at a
> >time and its easy to know which have been delt with.
> My worry with piecemeal is obviously an incomplete transition. While we
> have that to some extent with David's patches, we don't generally have two
> ways to get at the same hunk of data.
yeah, I'd expect there's enough incentive for conversions to be
finished, but really I should probably know better ;)
fortunately I have a patch that just needs a ChangeLog finishing the
conversion of INSN_DELETED_P (though to a member function). LABEL_NUSES
is harder in large part due to JUMP_LABEL, so that will probably have to
> >I also do think the advantages of using members outways the cost.
> I don't think it's always the case, but my general preference will be to go
> to member functions.
> >For one thing functions with all caps names are just weird. I think the
> >more important reason though is that it will help make rtx_insn be a
> >separate class sometime in the far future, since at some point we can
> >make its inheritance from rtx_def protected to chase down things that
> >try to convert from rtx_insn to rtx. There's also the argument that its
> >inconsistant to have some things be members and others be functions.
> Yes, the all caps is weird. There was a time when the all caps designated
> that we were using a macro and it was expected to be very efficient. When
> calling a function we were supposed to use lowercase to signify the likely
> high overhead.
I actually care because if I suspect its a macro I'm going to grep for
'define XXX' and if its a function '^xxx', but I guess I should just
remember to use ctags :p
> I'd tend to lean towards #1. If we want to convert to methods, I think that
> can be a follow-up. Type safety is my focus right now, not pushing towards
> member functions.
yeah, if you don't want to change things incrementally I think there's
less incentive to change this at the same time.
More information about the Gcc-patches