[patch] More thorough checking in reg_fits_class_p

Richard Earnshaw rearnsha@arm.com
Mon May 21 14:48:00 GMT 2012


On 17/05/12 14:23, Jim MacArthur wrote:
> On 02/05/12 14:55, Richard Sandiford wrote:
>> Richard Earnshaw<rearnsha@arm.com>  writes:
>>> On 02/05/12 14:00, Richard Sandiford wrote:
>>>> Jim MacArthur<jim.macarthur@arm.com>  writes:
>>>>> New Changelog text:
>>>>>
>>>>> 2012-05-02 Jim MacArthur<jim.macarthur@arm.com>
>>>>> * recog.c (reg_fits_class_p): Check both regno and regno + offset are
>>>>> hard registers.
>>>> Thanks.  I still think the final:
>>>>
>>>>> +	&&  HARD_REGISTER_NUM_P (end_hard_regno (regno + offset, mode))
>>>> check belongs in in_hard_reg_set_p, since most callers don't (and IMO
>>>> shouldn't need to) check this.  The idea behind adding these functions
>>>> was to commonise various bits of code that were doing the same checks
>>>> in slightly different ways.  Requiring each caller to check the end
>>>> register would go against that to some extent.
>>>>
>>> If you're going to do that (which is fine, BTW), I think
>>> in_hard_reg_set_p should gcc_assert() that regno is a valid hard reg.
>> Sounds good.
>>
>> Richard
>>
> 
> Sorry for the delay in responding to this, I had a few problems with 
> end_hard_regno. Here's a new version of the patch, which adds to 
> in_hard_reg_set_p the assert and a check for the hardness of end_regno.  
> end_hard_regno is the exclusive upper bound of the range, so not 
> actually a meaningful reg no. HARD_REGNO_NREGS is required to return a 
> positive value, so (end_regno - 1) is always safe, as I understand it.
> 
> I've tested this with an x86 bootstrap which shows no errors, and with 
> our own AArch64 back end.
> 
> Jim
> 
> New ChangeLog text:
> 
> 2012-05-17  Jim MacArthur<jim.macarthur@arm.com>
>        * recog.c (reg_fits_class_p): Check both regno and regno + offset are  
> hard registers.
>        * regs.h (in_hard_reg_set_p): Assert that regno is a hard register and
> check end_regno - 1 is a hard register.
> 

OK.

R.



More information about the Gcc-patches mailing list