Using gen_int_mode instead of GEN_INT minot testsuite fallout on MIPS

Richard Sandiford rdsandiford@googlemail.com
Fri Sep 13 08:43:00 GMT 2013


Richard Biener <richard.guenther@gmail.com> writes:
>> Yeah.  I don't think it makes sense to canonise PSI to 32 bits when we
>> know it has fewer than 32 bits.  It's still going to be wrong, and will
>> still defeat one of the main purposes of canonical constants, which is
>> to make equality obvious.  E.g. we'd still treat PSI constants
>>
>>   (const_int 0x...ff80000000)
>>
>> and
>>
>>   (const_int 0x...ffc0000000)
>>
>> as different, even though they're both zero for a 24-bit PSI.
>>
>> This partial integer mode stuff is just a big hack.  Like you say,
>> we can only really do something sensible if we know what the real
>> precision is.
>>
>> So I'd rather leave things as they are for this series.  The precision
>> effectively becomes 65535 thanks to the underlying unsigned short array,
>> so like you say, trunc_int_for_mode is a no-op for partial modes.
>> Changing GEN_INT to gen_int_mode shouldn't make any difference.
>>
>> What do you think about the patch for CC modes?
>
> I wonder if we can do without changing gen_int_mode by fixing the callers
> like you did for cse.c (that patch is ok).

But the point of the gen_int_mode patch is that (for better or worse)
CONST_INT is the right choice of rtx for constant CC values.  I'd like
eventually to get rid of all GEN_INT callers, and some of those callers
will sometimes or always be handling CC modes.  This would then crop up
again in a legitimate context.

IMO, cse.c was buggy not because it was trying to generate a CCmode
CONST_INT, but because anchor optimisations involve addition, which
isn't defined for CC modes.

I think gen_int_mode should do the right thing for all CONST_INT modes.
gen_int_mode (X, MODE) should really be the moral equivalent of
gen_rtx_CONST_INT (MODE, X), despite the confusingly-swapped parameters.

Thanks,
Richard



More information about the Gcc-patches mailing list