[PATCH 1/2] add staticly checked label_nuses accessors

Trevor Saunders tsaunders@mozilla.com
Fri Sep 5 17:13:00 GMT 2014


On Fri, Sep 05, 2014 at 10:43:45AM -0600, Jeff Law wrote:
> On 09/05/14 09:32, tsaunders@mozilla.com wrote:
> >From: Trevor Saunders <tsaunders@mozilla.com>
> >
> >Hi,
> >
> >  Doing this means we get to remove a fair chunk of runtime checking.
> >
> >bootstrapped + regtested on x86_64-unknown-linux-gnu with no regressions.
> >config-list.mk with this and the next patch is ongoing. ok?
> >
> >Trev
> >
> >gcc/
> >
> >	* config/i386/i386.c, config/i386/i386.md, config/mep/mep.c,
> >	config/mips/mips.c, config/nios2/nios2.c, config/s390/s390.c,
> >	config/sh/sh.c, reorg.c: Use rtx_code_label::nuses and
> >	rtx_code_label::set_nuses where possible.
> >	* rtl.h (rtx_code_label::nuses): New member function.
> >	(rtx_code_label::set_nuses): Likewise.
> Is there some reason why we don't fix every reference to LABEL_NUSES to use
> the new member functions?  My concern here is that we've now got two ways

 The reason I left some as is was because we didn't already have an
 rtx_code_label * there, so I was going to handle those later.  Though
 actually I guess we could adjust the macro to be

 #define LABEL_NUSES(l) as_a<rtx_code_label *> (l)->nuses ()

Whcih also has the advantage it doesn't compile if you pass in an
rtx_code_label *, and so you need to change to the newer form.

> actively used to get at that information, the old LABEL_NUSES and the new
> member functions.  Obviously we really just want one blessed way to get/set
> that information.  If this is a short term situation, then I'd be inclined
> to say OK, but I don't see further patches which sort out the ~200 or so
> LABEL_NUSES users.

because they haven't been written yet :) but I'd expect as types are
made more specific that situation will get better.

> THe approach David has taken for similar situations has been to first
> introduce the get/set methods, convert everything to set the get/set method,
> dealing with the type fallout that occurrs around that, then collapsing back
> to the old macro.  Is there some reason we can not or should not do that
> here?

I'd say we're doing the first parts of that here, but its not complete
yet.  That is I added the getters, and converted some but not all users
over.  There's certainly more patches to write though.

yes, basically the same thing is true for the other patch though we may
be much closer to finishing that conversion.

Trev

> 
> jeff
> 



More information about the Gcc-patches mailing list