[PATCH 1/2] add staticly checked label_nuses accessors

Jeff Law law@redhat.com
Fri Sep 5 16:43:00 GMT 2014

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 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.

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?


More information about the Gcc-patches mailing list